Project NASA Constellation SC

[simcosmos]

NASA Constellation SC
(NASA CxP SC)



----------------------------------------------------
I. Objectives
----------------------------------------------------

To provide orbinauts with a 'standalone' and coherently integrated addon about NASA's canceled Constellation Program (CxP).

I'm aware that several addons already do exist about the topic. However, each addon has its own specificities that makes it different and special, depending of the simulation and implementation objectives of each author. From my perspective, extra toys are never enough!



----------------------------------------------------
II. Introduction:
----------------------------------------------------

With this addon I then wish to clean up the years old dust from a few toys of my 'simcosmos' archives and (finally!) share them with the community. These toys will be powered by Vinka's multistage2.dll and spacecraft dlls, which are more than enough for the current simulation goals (on Orbiter2010 P1).


In order to differentiate this implementation from other works, I will focus / extrapolate from less known design iterations of Constellation hardware. At first, the attention will be directed to the lunar return effort. Other uses of Constellation hardware may also be considered *after* the lunar variants are published although I do not plan to overly extend the development on such direction because that will be an objective for another set of simulation files (NASA VSE SC alternative reality, whenever I release those!).


Back to CxP elements: the Ares I / Orion elements are the ones for which more mature data is available. The AresV / Altair were still in a much more highly conceptual phase and, because of that, I will provide one of many possible paths that could have been chosen for their development.


The simulation will also try to follow a set of ground rules in what regards the implementation of performances and mission design: I find that this kind of procedure – even if the simulation is based on generic dlls - helps to improve the realism of the implementation although it may pose some challenges for less experienced orbinauts. In any case, if needing extra margin, a part of such rules may be 'bypassed' by the final user, for example, simulation of boil-off or some mission margins are optional (!) and then there is always the possibility for each one to tweak the simulation by playing with the configuration files (and I can also help by later implementing a more capable variant of the baseline files)...

As usual, this will be an 'what if' exercise: extra details (and previews) will hopefully be provided on this thread.




---------------------------------------------------------------------------
III. A word on Addon Requirements / Integrations
---------------------------------------------------------------------------

As noted, the goal is to make it a download-unzip-play addon. Any other thing that may be needed will be an extra, a nice-to-have component which will not be required for the core addon to work.

Such extras could include:
- Dansteph's Orbiter Sound (if people wish to have sound)
- simcosmos FX Pack (not yet released, but the idea is to move sounds into a kind of external library, instead of including them within each of my addons... this makes the addons much smaller in file size and centralizes those resources).
- Integrations with addons from other authors (yes, francisdrake is at the top of the list): the scenarios and eventual other files will be inside the core SC addon but the user will need to download the external addon or else there will surely exist a CTD when playing such scenarios!
- A variety of other addons may also be suggested to improve aspects of the simulation but they will not be really required to enjoy the core package (example: specific MFDs, Dansteph's UUMU + Computerex's UUMUFA, etc).




----------------------------------------------------
IV. Extra Notes / Thread Updates
----------------------------------------------------

This section of the post is where I may call the attention for:

IV.a) Important topics within the thread:

Note: in order to provide a better context to some of the topics that I have been writing about (and that will still write) as well to allow for a better context of this addon's conceptual brainstorms, I highly recommend, to everyone interested, an attentive reading to the two following pdfs. These are just a couple of many available documents out there but they should give a good summary of Constellation Program and its requirements impact, for example, on HLV design assumptions (this will be good for when I share my custom AresV concept).

Executive Summary of AresV:
Lunar Capabilities Concept Review Through Phase A-Cycle 3
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20110008314.pdf

Ares V Utilization in Support of a Human Mission to Mars
http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100042324.pdf


IV.b) Or suggest the main topic of an upcoming development post

:hello: Next main development post may be about:
- Sharing preview (context + image) about Orion-Centaur (Lower Bookend Missions)
- Custom Launchpads


IV.c) Or will be the place where will link the addon, when uploaded at OHM.

(not yet released)

Thanks,
António Maia

End of original message:
For now, will just attach a first preview, showing a render of a number of different solid booster options required by some of 'simcosmos' toys (from right to left: the 2nd and 3rd ones are the baseline for the CxP SC addon)

 

[IronRain]

Really looking forward to see the progress! :thumbup:

 

[simcosmos]

Hi all

Thanks, here goes a new development post and render:


NASA CxP SC (Dev Phase1): AresI
(and a little about Orion)


------------------------------------------------------
I. CxP SC: Addon Development Background
------------------------------------------------------

Instead of releasing all in one go, I will start by updating what believe is really crying out loud for such update... And that is the older NASA_AresI_SC_20070107dev.zip:
[ame="http://www.orbithangar.com/searchid.php?ID=2770"]NASA AresI SC - 20070107dev[/ame]


The objective of the older AresI implementation was to share development synergies with francisdrake's cool CEV-Orion work, with Franz sharing an 'Orion launch .msh' and previews of the spacecraft, with me providing an AresI (meshes, textures, configurations and also some notes about Orion specs, etc) powered by Vinka's multistage2.dll and with francisdrake then re-interpreting / recoding the launcher into a specific. dll + including those files in his own CEV-Orion addon.

Meanwhile, other things got in-between and, after the '20070107dev' release I was not able to continue updating my side of the Vinka's multistage2.dll version of the launcher, in order to keep up a good integration with later variants of francisdrake's CEV-Orion (I believe the latest was / still is the 0i). Only to give a better idea of the timeline, we are talking about events that started when the main Orbiter forum was still the M6 version!




------------------------------------------
II. Moving on: AresI Updates
------------------------------------------

I will probably use the above 'ID=2770' OHM link to upload the new generation of 'CxP SC' files: so, if anyone wishes to keep a copy of that older and outdated '20070107dev' zip for archive / historical purposes, please download it while it still is online (no rush, I will warn before uploading the new stuff, it will not be this week).


In order to not overcomplicate too much, custom launch pads + MLP will probably be left for another update. So, for the upcoming zip I decided that will just include:
- revisions to the directory structure and to files designations (in order to avoid, as best as possible, some issues that may currently exist due to a number of different reasons, including management of possible conflicting versions of the 2007dev files)
- updated AresI / Orion, as described next...


II.a) AresI List of Updates:

II.a.1) Simulation of a 5 seg. SRB (PBAN):
For the '20070107 dev' AresI version I included a 5seg. HTPB design (parameters, thrust curve) based on STS upgrade materials (on NASA VSE SC alternative reality, that upgrade is assumed to have happened between Challenger and Columbia tragedies). Such data was what I had at hand at the time and decided to implement it for AresI booster, to help a little more the upper stage work.

But now things are different, several years have passed, Constellation came and went, some pieces kind of survived (Orion MPCV, 5 seg. SRB)... To sum up, there is a LOT more available information about Constellation (real) hardware than what was usable when the original addon was made. Because of that, the upcoming CxP update will now adapt a thrust curve from a previous 5 seg. SRB (PBAN) test related with AresI / SLS real development!

As can be seen in the preview image (original post and others that may follow), the whole booster will have a number of visual updates that better reflect one of the latest known AresI iterations (with wind tunnel work). I do not pretend to be exhaustive about capturing every minor detail to the last mm... there are obviously a number of simplifications, mistakes, other things are missing, other details are personal touches... I usually do not go for maximum 1-on-1 detail. The objective is more to capture the dimensions and generic 'feeling' of the stage(s) (and the same will be valid for all other components).


II.a.2) Upper Stage
A new render preview is being shared today (please see attachment at the bootom of the post), showing the upper stage 3D model updates that (try to) reflect such late AresI design iteration.

For comparison, the model version used on 20070107dev:

NASA_VSE_SC_DEVWIP20061219simcosmos_AresI2ndstg by simcosmos, on Flickr


In terms of performance implementation, full J-2X specs will be now assumed (~1308 kN instead of 2007 addon's 'risk reduction' variant called J-2XD, with a lower thrust of ~1218 kN and which development was meanwhile abandoned).

Another change (total prop. load): AresI upper stage initially had an intertank which was removed to make the stage shorter / lighter (this was what I tried to represent in the 2007 files). Meanwhile, some performance threats appeared and the stage kept the common bulkhead but went back to an increased tank length (addition of ~10t of extra prop.). This means that the upcoming stage will have its prop. load increased to ~140t (instead of 2007's ~130t).

The overall stage related masses (+ interstage) will also see a non-trivial increment on total mass (~> 4t!).



II.a.3) Performance Threats and Trajectory Work
The solid first stage and upper stage updates will then try to reflect several types of mass growth: some types are caused by specificities of AresI-Orion integration (we are far from the ' safe , simple , soon '), some other are caused by mass growth on individual components (both on launcher AND payload, independently of integration challenges).

Things like - but not limited to - the full J-2X spec and improved prop. load of the upper stage are then a few of the measures taken to gain back performance for the integrated AresI-Orion configuration.


This all to briefly mention that the upcoming performance and ascent guidance files will also try to be a little more carefully encoded, under a set of adopted simulation rules. Those rules may not be all strictly followed yet but they do greatly help on constraining parameters that have an impact on performance. The hope is that these steps will improve the fidelity of the performance assessment of the concepts(s), despite other constraints and simplifications related with the implementation method.

I'm not sure if will list all the rules in an upcoming fresh development release (the documentation is a work-in-progress and will not be fully written) but, only to give a few examples (focusing for now only on ascent groundrules) I'm talking about things like:
- trying to constrain the AOA excursions, during first stage (especially while crossing the denser atmospheric layers), to less than 3 or even less than 2 degrees (ideally as near to zero as possible during transonic-to-maxQ)
- or things such as keeping the vehicle with a stable attitude during key separation / jettison events
- ensuring that such events happen at correct conditions (vs trade on performance impacts vs staging objectives, for example, AresI pitch program could be different if recovery requirement for the first stage would be abandoned)
- simulation of thrust transients, non-instant staging events
- rules for % of initial prop. load left as part of burnout mass (depending of stage type and mission goals)
- and so on, and so on...



III. Orion Integration(s)
I was planning to share, with this post, a few additional notes about Orion and its integration but this already resulted in a long text so I guess that it may be better to leave that (and new renders) for a next post because, if possible, I would like to have a little of feedback regarding that specific topic (external addons integration vs requirements vs my own version of Orion).

Depending of such eventual feedback, I will finalize the decision about what to include (in terms of payload integration) on the first fresh 2015dev release that will replace the older 20070107dev files.

Meanwhile, hope these previews are a fun / interesting thing to read.

Happy flights,
António Maia

 

[4throck]

Looking great. :thumbup:

 

[K_Jameson]

Fantastic mesh for the upper stage.
But Ares 1 was a mediocre design... why bring it to life again?

 

[4throck]

... because it's part of Constellation I guess ...

 

[K_Jameson]

Obviously...

Maybe i didn't understand the spirit of this project but, if we are in the "what if" domain, some creative license can be allowed. In this case, a more reasonable choice for Orion LEO launch could be Delta IV Heavy.

 

[orbitingpluto]

Obviously...

Maybe i didn't understand the spirit of this project but, if we are in the "what if" domain, some creative license can be allowed. In this case, a more reasonable choice for Orion LEO launch could be Delta IV Heavy.

While simcosmos did say he's going to look at less well known design iterations, I doubt that's going to be on the menu, any more than dropping the Ares V for the DIRECT family. Some pieces of Constellation are just too immutable.

 

[K_Jameson]

Some pieces of Constellation are just too immutable.

Not quite so; just look at the SRB: four segments at first, then five segments, and finally five segments and a half for Ares V (and commonality lost between the two rockets).
Also the Ares V core configuration was "fluid" even in the last times, just look at the ever changing RS-68 arrangement (five, then six, then six in another disposition with large thermal shroud...).

 

[simcosmos]

Hi all

Thanks,

Some comments:

The 'what if' component of the addon is related with:
a) less known but still part of official design iterations of CxP hardware
b) and/or still open trade spaces or other things related with eventual solutions that could protect the intended capabilities (focusing here on the lunar return, for now)

Not quite so; just look at the SRB: four segments at first, then five segments, and finally five segments and a half for Ares V (and commonality lost between the two rockets).
Also the Ares V core configuration was "fluid" even in the last times, just look at the ever changing RS-68 arrangement (five, then six, then six in another disposition with large thermal shroud...).

K_Jameson, your quote above is also one of the reasons why I'm making this addon: it is very difficult to pick one topic without talking about other issues because it is all interlinked.

My plan is to use this thread to provide more background for each one of the components to be included within the CxP addon and, while doing that, the 'spirit' of the addon should perhaps be better clarified. But I only have two hands and the best way to do it is perhaps in a phased way, or else each one of my already traditionally long posts will virtually become authentic papers!

For the moment, I will then try to answer your comments and then, as the development previews continue, I hope to clarify it all a little better.




------------------------------------------------------------------
I. AresI vs AresV : Development Commonality
------------------------------------------------------------------


First of all we need to clearly distinguish between two very different things: ESAS Report recommendations for VSE implementation and the actual Constellation Program implementation.

I. a) ESAS recommended:

CLV = 4 seg. solid FS PBAN (STS booster transformed to on-line stage) + RS-25 US (with intertank)

CaLV = 8.4m diam. CS with 5 RS-25 + 2 x HTPB 5 seg. SRB (with aggressive specs) + US with twin J-2S+ (with a somehow also challenging ISP assumption)

Regarding spacecraft, I will not list all details, but an important one that need to mention is that methane-lox played a key role for CEV's SM and for LSAM AM.

Regarding the crewed lunar mission mode, will reference the '1.5' mission mode: one smaller dedicated crewed launch vehicle and a bigger cargo heavy lifter. EOR, TLI, LOR to get back home. Going to the Moon and return back home 'Anytime, Anywhere' goals.


I.b) Then, there is Constellation Program, the actual implementation:

The ESAS CLV design was recommended because was perceived as the quickest to implement in order to reduce the gap (STS retirement). That CLV was not free of development risks though (mostly related with in-line solid stage integration and the RS-25 US) and Constellation Program reached the conclusion that even if the LV could probably be ready in time, CEV, later called Orion, would not.

Then there were other important issues with ESAS recommendations, mostly regarding margins protection for the '1.5' mission mode (examples: maximum CaLV performance vs boiloff not being taken in account, etc!)...

So, early on, Constellation did a number of changes to ESAS recommendations that had its logic...
- AresI US powered by J-2X, which would also be used on AresV EDS
- AresV CS synergies with Delta's RS-68 (and CS increased to 10m to compensate for the lower ISP)
- AresI developing a 5 seg. PBAN (STS heritage, recoverable) FS which would then also be used by AresV in booster role, etc...
- Methane-lox (Orion SM and Altair AM) changed to hypergolics due to perceived higher risk of methane
- EDIT: Orion's CM reduced from 5.5m down to 5m (but apparently still with mass expectations close to the 5.5m diameter one, at least looking at MPCV info)...


So, focusing in AresI, the CxP configuration changes seem logical IF, despite all known implementation challenges:
a) IF the solid booster would have been recoverable (not strictly necessary to be always recoverable and/or reusable)... the high staging condition (vs a more standard booster role) was a challenge for recovery and... deleting recovery requirement was also one 'easy' place to buy-back performance, if needed... we will never know, but we can make educated guesses, run some numbers and make them available for peer review, like what I'm trying to do here!
b) IF AresI would have indeed shared synergies regarding the development of key components for the heavier AresV...


Again, there would exist a lot more to write but the basic idea behind AresI was an easier-to-launch crewed vehicle and something that could also be used as a gap-filler and development platform for the HLV. Of course that this part of the logic greatly starts falling apart, for several reasons (safety concerns included, also replacement costs, etc), if the requirement for the recovery of AresI first stage would have been abandoned and if, for example, the AresV design would eventually end up by requiring a different booster design than the one developed for AresI... a never-ending development program is not something very practical, even if the advantages of something better - than the already mighty 5 seg. SRB PBAN design - would be good for extra performance / margins protection. (this type of subject is still present regarding SLS...)

However, this should all be looked at in a more integrated way and, VERY IMPORTANT (sorry the caps) having always present several constraints (including political)...

Focusing in Orbiter simulation purposes, and only on technical vs mission design constraints, the intended lunar return requirements (4 astronauts on lunar surface up to ~one week in sortie mode, 'anytime, anywhere' vs lunar loiter times for LOI and TEI, etc, 14t up to 17t single launched cargo payload, eventually building a base, etc) and the crewed mission mode called as '1.5' do pose several important constraints on the hardware...


These '1.5' constraints and the integrated choices that (try to) solve the 'problem', as a whole, are a very interesting and somehow complex exercise, and this is what I'm then trying to present with the current addon development: a possible fully integrated solution, not THE solution (other addon authors would probably arrive to other conclusions, extra fidelity on the simulation could also end up by leading to other choices...)


As an example of what is written in the above paragraph – and now focusing in AresV - the HLV design iterations did not stop at the point you mention... In fact, in later 'Points Of Departure' for AresV, the preference was back to a 5 engine (extended) core (which is the option that I will explore here), with the 6 engine configurations still kept in the trade space but really more like a maximum performance, everything-else-fails-alternative... 6 RS-68 are kind of hard to integrate (thermal environments vs also thinking in Core Stage geometry vs MLP, etc).

And YES, in that trade space, there were also options that were keeping a greater commonality with the AresI FS (example: recoverable steel casing 5 seg. SRB, PBAN, same prop. amount as AresI, although with a tweaked thrust trace, for a more powerful / short burn, more optimized for AresV role)! In this aspect, I will go a little further (EDIT: I mean, going further in the sense of using a more conservative assumption) and even baseline, in my custom AresV configuration, the same design as in AresI (no optimized thrust curve)...

Of course, it is also very evident that in case of severe mass growth of several mission components (including AresV itself), an optimized booster would greatly help in buying-back performance... And this is why I shared, in the first preview, that concept similar to Dark Knight booster, I mean, in case fellow orbinauts are finding the baseline configuration an harder challenge to crack vs fun vs playability

But these are all details that I was planning to properly layout on later preview posts (about my AresV implementation) and / or in the addon's documentation. Same is valid regarding Altair or more about 1.5 mission constraints, etc.




------------------------------------------------
II. AresI vs DeltaIV Heavy
-------------------------------------------------


I do not think that AresI was a mediocre design although I understand the reasons why many may share a similar opinion about it. And yes, at the same time, I also do think that something else could equally do the job of AresI, under a set of additional contextual constraints. These two opinions are not necessarily mutually exclusive.

However, for the good or for the bad, and only in terms of technical discussion, I find that there may sometimes generically exist a lack of some integrated perspective, from the point of the overall CxP requirements and their impact on the specific hardware design choices. This addon will try to explore that angle and to do such, AresI really needs to be included and play a key role in an addon with the name 'Constellation' on it


Nevertheless, I may share a rough render preview of a DeltaIV Heavy (in CLV cfg) at the side of AresI: I already had the performance implementation running on top of placeholder meshes but the 3D stuff that is in the 3D editor is still being (re)worked (and those are the meshes that I plan to release)...

So, yes, I could then eventually imagine a context, within this CxP addon, for such DeltaIV Heavy to be coherently shared, for example, if later breaking the commonality between AresI-V by introducing something like the Dark Knight booster. AresI would then need several adjustments to use a Dark Knight as FS and it could be preferable to retire it instead, also given that J-2X and first generation boosters were already developed for the HLV and given that an alternative DIVH would exist as CLV... But, if doing it, such will probably only happen after all the 'traditional' Constellation elements are released.

Because... and we always come back to this: I really, really , really only have two hands!


Ok, later today I will try to attach here such AresI vs DeltaIVH rough render.

Meanwhile, hope to have clarified some aspects of the addon's goals.

Thanks,
António Maia

EDIT:Image shared, but it is just a 'little distraction', the DeltaIVH is not textured, still some details to model. But the priority here is currently going for the AresI update / Orion integration: hope to share some more stuff about that for a next post.

 

[orbitingpluto]

Not quite so; just look at the SRB: four segments at first, then five segments, and finally five segments and a half for Ares V (and commonality lost between the two rockets).
Also the Ares V core configuration was "fluid" even in the last times, just look at the ever changing RS-68 arrangement (five, then six, then six in another disposition with large thermal shroud...).

My argument was a poor one, and if I had given it some more thought I might have argued that Ares I as a concept, a Shuttle(or sort of Shuttle-derived) SRB as a first stage of a crew carrying vehicle, was the immutable thing. Once the Stick design was bought into, it was stuck to, morphing the basic idea again and again to fit to the changing requirements.

But I didn't, and since simcosmos is better equipped to argue his own reasons for developing an Ares I, I think I ought to bow out of the active discussion before my foot finds it's way to my mouth again. I'll still be reading, so I might post again, hopefully better prepared next time.

 

[K_Jameson]

Hi all
EDIT:Image shared, but it is just a 'little distraction', the DeltaIVH is not textured, still some details to model. But the priority here is currently going for the AresI update / Orion integration: hope to share some more stuff about that for a next post.

I like the render! What program you use?

---------- Post added at 08:18 AM ---------- Previous post was at 08:05 AM ----------

Once the Stick design was bought into, it was stuck to, morphing the basic idea again and again to fit to the changing requirements.

The Stick configuration was gradually morphed for a bunch of reasons: first, the Orion weight problems; second and even more important, the extreme difficulty and costs for making the RS-25 engine air-startable. That, in the FOI fictional rocket science, was perhaps the main motive that lead to move from Jarvis M "Block I" to the "Block II" (moving the RS-25 from the second to the first stage, with ground starting instead on-air).

Returning to Ares I: they abandoned air-startable RS-25, then moved to J-2X (equally expensive, but at least air-startable from the beginning), but giving the much lower thrust (and ISP), the four-segments first stage was not sufficient anymore for matching the required specs, forcing it to move on the five segments (with others additional costs).
Similar problems (switch from RS-25 to RS-68, lower ISP, more fuel request, consequential enlargement of the core stage, more weight) has lead, in Ares V, the forced move to the five and a half segments (other costs, lower commonality with the Stick).

 

[simcosmos]

Additional comments, like I wrote, this is all interlinked:

I. The Constellation changes to ESAS recommendations (and after that) were caused by mass growth of several components, revised margins of several order (including better margins for vehicle development and mission design than what was included in ESAS) and to (try to) reduce development costs

I mean, instead of having what would essentially be two upper stage development programs (air-startable RS-25 for AresI and re-startable J-2S+ for AresV), Constellation consolidated requirements into a single J-2X engine development program with a compromise in thrust and ISP that would satisfy both vehicle requirements.

Another important detail was the wish to only use a single engine configuration on AresI US, which, I agree, mostly due to the lower thrust of J-2X (vs RS-25) then required an upgraded 5 seg. first stage (vs 4 seg. first stage)... But given that Orion would not be ready in time anyway, this would be advantageous for AresV development (by sharing the same 5 seg. booster).

As a side note, if the single engine constraint was removed from AresI (because of those funny LOC / LOM calculations), the 5 seg. vehicle could also work with a twin J-2X setup (without the long nozzle): thrust is much more important than ISP in AresI application... something as low as 436s ISP could be enough... This is based in my own simulations and later confirmed by people who actually worked on AresI.


Concerning AresV, I do not quite agree with some things: yes, any RS-68 variant will have a lower ISP than any RS-25... And, as correctly mentioned by K_Jameson, the AresV core diameter increased to 10m in order to compensate for it (in that we agree). Of course that such enlargement also causes extra mass but we can then not exclude, from a complete comparative analysis, that the RS-68 has another key difference from RS-25: a LOT more thrust (and although a RS-25 powered core stage is more efficient it may also find sooner its maximum allowable prop. load carrying capability).


I also stress again that the five and a half seg. booster was part of one of the AresV baseline configurations (LCCR), which was meanwhile replaced by a later Point Of Depature vehicle which would use instead something with a little more commonality to AresI developed booster.

Such later design iterations resulted from a more profound analysis where Constellation Program evaluated lower and upper bounduaries for AresV performance vs development timeline vs development risks and costs vs updated margins for all (including mission designs) vs Moon-Mars synergies, etc. Designs such as five and half seg. boosters, HTPB, composite casings were kept in such trade space but there were several more options and combinations (regarding number and RS-68 type on core stage, EDS and core stage materials, etc)

EDIT: in my opinion, one of the biggest... I would not call it mistake... but one of the biggest 'always lurking factor' in Constellation, once chosen the 1.5 mode, was the lack of budget to develop a proper new engine for the HLV core... I also think that other mission mode would probably have been better (as well CLV / booster choices, etc, but that is not Constellation)


II. I propose a conceptual exercise to readers:

Forget AresI, replace it by whatever dedicated crewed launch vehicle you may prefer that lifts a full lunar spec. Orion... This Orion (CM+SM) could be ~23t (= to ~21t or so at TLI) or closer to ~25t (= to ~23t or so at TLI), if being less optimistic.

Forget about AresV as usually seen in CxP materials (I mean, RS-68 CS with 10m diam.). You could even assume a core stage powered by 5 or 6 RS-25 or even something else for the HLV. Do not directly use ESAS report old numbers for such SDLV masses: update them to reflect more mature assumptions and margins (same for mission design).

Do the simulations (with updated ascent and mission groundrules!) and math for HLV's total mass injection into ~241km 29º and for the '1.5' mission mode.

Examples from my simulation files:
(please see original post at http://forum.nasaspaceflight.com/index.php?topic=32911.msg1120694#msg1120694 , with additional details)

~181t, 241 x 258 km (~58t TLI, if single launch mode):
- kerolox LRB (personal musing, 4RD-180 or 2RD-173 per booster or similar), 5 RS-25 core
~158t, 240 x 245 km (~47t TLI, if single launch mode):
- Dark Knight SRB (personal musing / extrapolation, based on available info), 5 RS-25 core
~149t, 165 x 241 km (~42t TLI, if single launch mode):
- Dark Knight SRB (with HLV core having 5 – 1 = 4 RS-25)

From the mentioned above total injected masses (the very first number), there is the need to subtract (for a quick clumsy math on 1.5 mission mode):
- at least 45t for Altair (including adapter, and assuming strong mass control on Altair...)
- at very least ~3t (most probably greater mass than that) for a loiter kit (which will be left behind before TLI)
- and ~0.25% (up to 0.35%) per day of the initial total prop. load for an initial guess at boil-off simulation (3d to 4d at LEO or so)...
- then, there is still at least more than 20t of upper stage mass (probably between 23t and 25t, depending of assumptions) that needs to be accounted for...
- the remaining value should be propellant that needs to protect for a ~3175 m/s TLI burn (~3200m/s, if with stronger margins regarding losses)...
- from such propellant mass do not forget that some percentage should not be used on TLI and should be left inside the upper stage after the burn (residuals, reserves... ideally at least 1% of the initial total load... maybe more than that, perhaps somewhere between 1% to ~2% for extra margin...)
- ho, and do not forget to ADD the Orion mass (~21t up to ~23t) when doing the TLI dV calculation, for example assuming 448s or 450s ISP...

As can be seen, only when using a 5 RS-25 core (6 RS-25 may require additional assumptions) with liquid boosters is when I start having margins to do a 1.5 mission mode... A similar core (with 4 or 5 RS-25) and solid boosters could be good for LOR-LOR though (which is the mission mode I'm assuming in that another addon called NASA VSE SC)...



All the above to write that independently of dedicated crewed launch vehicle and of heavy lifter choice, keeping the 1.5 mission mode imposes several non-trivial constraints on the shoulders of the heavy lifter configuration, in particular if improving the detail of simulation vs needed requirements (and if some mission components – including the HLV itself - are not kept under severe mass control...)

I highly recommend, to everyone interested, an attentive reading to the two pdfs that I will soon link at the bottom of the introductory post of this thread... These are just two of many available documents out there but they should provide a very good context for several things related with this addon / Constellation Program...


Meanwhile, my next post will be more focused on AresI-Orion integration. I suggest that we could perhaps get back to a more extended AresV / 1.5 mission mode exchange of comments when I make the related previews, but everyone please do feel free to continue adding your perspectives about any of these topics

Thanks,
Antonio Maia

PS: Andrew (thanks) >> for the AresI vs DIVH render I used Right Hemisphere's Deep View (render) and then applied a couple of filters on the Image editor. Deep View is really cool, it allows cross section renders, comments and to do several other funny things with the 3D models (pull parts apart, re-assemble them, etc)

 

[K_Jameson]

I used Right Hemisphere's Deep View (render) and then applied a couple of filters on the Image editor. Deep View is really cool, it allows cross section renders, comments and to do several other funny things with the 3D models (pull parts apart, re-assemble them, etc)

Judging by your screenshots, it is a really cool program, i agree (i only use Anim8or)!
Also, i must say that your meshes appears to be of excellant quality, really ahead most of the works on OH. I'm a little afraid about the polygon count.

I would like to say a few words regarding my previous statement about Ares I as a "mediocre" design. In fact, I like Ares I, and I like the idea of a cheap and reusable solid first stage (an idea that I followed on FOI's Neptune-1 series of launchers).
But the solids has a downside on ground operations (you must transport a full stage instead of an empty tank that is filled on ramp) and especially security in case of an abort. Not counting the vibrations problem for the crew. In short, I like a solid rocket for the unmanned but I prefer a liquid-fueled for the manned flight. Also, Ares I was always in trouble regarding the performances, and was ever barely enough for the job, with no much room for development, at least in the known configuration. And yes, the existance of at least two US rockets with similar if not better performances (Delta IV Heavy and the ready-to-go Atlas V Heavy) make Ares I less attractive.

 

[simcosmos]

Hi Andrew,

By the way I like your Orbiter / FOI toys, some of them have interesting points of contact with my own development, for example, in the alternative VSE SC reality I later replaced a 5 seg. SRB HTPB design (assumed to have been developed for STS and, in such alternative world, would then have been more or less readily available for AresI-V) by a liquid booster (first played with kerolox but after baselined methane-lox). The liquid stage (the VSE SC AresI US is also an alternative design to this CxP one) allows for ~30t (AresI) payload (in flybackmode) or ~50t in expendable mode (but this is off-topic, hehehe)



Back to CxP, yes, I agree, that a solid first stage kind of constrains too much the trade space and is quicker at reaching a design limit (or in requiring more aggressive assumptions) than a liquid stage where, in a simplistic way of saying it, it is mostly a matter of increasing tanks and adding engines. :lol:


Another issue with solids, beyond what you well referenced, is the Quantity Distance (QD): number of segments in a given space vs possibility of something going... less well while assembling them.

Additional facilities at KSC may be needed to assemble the solids if assuming mission modes that require a faster launch cadence... The 1.5 mode would be already something more or less borderline, using 1.5 set of 5 seg. boosters. Dual STS (2 sets of 4 seg. SRB was also the limit). Anything beyond that... hummm, dual HLV launch with 2 sets of 5 seg. SRB... (or else 2 sets of 4 seg Dark Knights)... do not know, do not see much discussion about it except some pages on NASA's Mars DRM5 (and perhaps in ESAS Report too, would need to check).



About generic 3D topics / screenshots, I have not explained myself well, I also use Anim8or to model the toys. The renders are either produced in Anim8or's engine or, most of times, with the help of other external programs such as the Deep View example (for AresI vs DeltaIV Heavy case).

Concerning poly count: I try to use simplifications and to do some detail on texture, delete a little of unseen stuff (what I do not delete is because may need to use in other projects), etc. The meshes that I will share will not be optimized though (example: have not merged groups and I'm also a bit lazy when texturing). Really, they look nicer on renders and on screenshots than a closer inspection may reveal!

Quick stats of a couple of main parts that intend to release:
AresI FS: 475 KB, 5510 triangles (this includes interstage components)
AresU US: 457 KB, 4700 triangles

Don't tell anyone but I'm developing this on an EeePC 1000H (with external image output), if it runs ok here I think that will run fine anywhere but people can later give feedback about that

Cheers,
António Maia

---------- Post added at 18:10 ---------- Previous post was at 17:50 ----------

Hello again, I will leave this post and then may go a little low profile in the upcoming days. Meanwhile - and because I'm currently doing some AresI-Orion tests - I would like, when possible, to please have feedback about a number of topics, so that when I come back, one or two aspects of an upcoming release may be finalized.



-------------------------------------------------------------------------------------
I. Francisdrake's 3 Orions (CEV-E, Orion0i and OrionMPCV):
-------------------------------------------------------------------------------------


ATTENTION: those addons will be external requirements (properly referenced in documentation / scenario files): I will only include scenarios and launcher configuration with those payloads already integrated (together with the necessary adapters, fairings, LAS). The addons need to be installed or else there will surely exist a CTD!


I.a) CEV-E will simply use a cylindrical spacecraft adapter (CEV-E's SM 5.5m diameter is the same as AresI US). The SM will be exposed to ascent environments, unless I build a new kind of SM fairing for this specific variant, hummm, what do you all think?

CEV-E's CM diameter is also 5.5m (being based on original ESAS design), which brings me to a question about CEV-E's LAS: what would orbinauts prefer? Just a tower (this would be similar to the first real life abort test and to the older 2007 dev integration) or would orbinauts prefer to also see the CEV-E capsule being fully inside a protective cover?

The 5.5m CEV-E diameter makes it difficult to support other types of LAS but, if people wish a protected CM, I may probably introduce a simple(r) conical shape that would kind of 'follow' the outer CM walls... Or I could simply call my ogive LAS (similar to the preview of the last post), and we could all pretend that such design would be a realistic integration. I mean, the ogive cover 'needs' to interface (smooth transition) at the top of the SM (which is not possible on ESAS CEV because both the CM and SM share the same diameter).

I would then perhaps include the ogive LAS design on CEV-E, given that the .msh would be needed anyway for my custom Orion version and because, in terms of mass, it would probably save time regarding adjustment of ascent guidance... but I'm open to opinions about these topics.


I.b) Orion0i:

This is the version that francisdrake shared in his 'CEV-Orion' addon: I have adapted my conical spacecraft adapter in order to provide a smooth interface between the US and '0i' SM (because of little dimensional differences between my version and francisdrake). I also had to adapt my SM fairings by reducing their top diameter (Orion 0i seems to use a smaller ~5m maximum diameter for the SM).

Regarding the LAS, a similar integration issue (to ESAS CEV) is present: 0i's SM smoothly interfaces with the ~5m CM: I will probably just produce an alternative version of my LAS, with the ogive's cover diameter also reduced to ~5m, even if it becomes within the CM walls (it will visually look good from the outside).


I.b) Orion MPCV:

Similar comments to Orion0i: I needed to produce another variant of the spacecraft adapter and of the 3 SM fairings. Regarding the LAS, the comments would be similar too, but in this case, I will just call francisdrake's cool LAS .msh already included in the MPCV files.




----------------------------------------------------------------------------------------------------
II. AresI Tests: Vinka's Multistage2.dll : Orbiter2006 vs Orbiter2010
-----------------------------------------------------------------------------------------------------


All AresI files (.scn, .msh, .dds, .cfg and .ini, Vinka's dlls) for a fresh update to my older '20070107dev' are already in their proper directories: the launcher looks good.

I have however noticed two development issues:


II.a) Multistage2.dll 'Drag Compatibility Bug' in Orbiter2010:

What I will write next isn't probably fresh news but I will leave it here for reference: the performance of multistage2.dll launchers are consistently slightly better in Orbiter2010 than in Orbiter2006... With the ' F4 > Visual Helpers > Body Forces ON ' it is easy to see that the changes in Orbiter2010 may have caused some compatibility issues on aerodynamic parameters of multistage2.dll...

In Orbiter2006 I then have a good drag vector display from liftoff all the way to about 85km altitude or so... In Orbiter2010 such drag vector still appears, but really mostly around the time for maximum dynamic pressure and/or at other times, with reduced values (compared to Orbiter2006)...

Snif, this kind of 'breaks' some things regarding the performance assessment of the launch vehicles... Without surprise, Orbiter2006 + multistage2.dll are a more stable combination.

I will still have to decide how will work around this issue... Will probably have to introduce some kind of performance penalty on Orbiter2010 implementation...


II.b) My virtual version of a Thrust Oscillation 'Burp'

When doing ascent tests also noticed a 'burp' (minor jump) on the 5 seg. first stage thrust: this was being caused by a ',' instead of a '.' in one step of the thrust curve definition. The burp has already been solved but a later version will need further adjustments (even without the 'burp' the thrust curve would still have required a number of extra tweaks anyway, it will be a WIP).

AresV's boosters are not affected by the 'burp' because their thrust curve is implemented at a lower resolution (using multistage's INI thrust curve function) than the one in AresI (which uses thrust commands in the guidance file to increase the number of points for thrust curve simulation).




-------------------------------------------------------------
III. Orion607-SC, New Previews, Decisions
-------------------------------------------------------------


Despite the 'standalone' (in terms of external addon requirements) final goal of the addon I'm seriously thinking about releasing a first version of what I have now running here in what I think are acceptable conditions... At least it should be an improvement on the older '20070107dev' files.

For such first update, I will probably NOT include my own Orion because the CM is lagging a bit behind... It is mostly an outer shell, no virtual cockpit, only basic mass properties... and with a 'brick mode on' entry capability... It could be OK for visual placeholder on ascent and orbital ops but I still need to do the boring task of implementing parachutes, RCS definitions, etc (in my other alternative 'VSE SC' the Orion would have been a more advanced / heavier design, with full propulsive landing capability - LAS would still be an independent system - and an optional main drag element which would be 3-duty... much 'easier' for addon implementation and reusable hardware perspectives, hehehe).


If possible, I would please like to read opinions about:

III.a) the LAS (integration) questions vs different Orion versions

III.b) and would also like to please know what do you think about releasing a first update which would still strictly require external addons to work (delaying the standalone objective for a later update)... I suspect the answer will be: 'YES, bring it on, baby!', but I'm asking anyway

III.c) Of those addons (for now focusing only in francisdrake's Orions) is there an order of preference for their integration as AresI payload?
Only asking because each one of such spacecraft will require a number of tweaks (beyond LAS) on the ascent guidance: they have different total payload mass properties, which affects the timing of some jettison events and also need adjustments, mostly later on the ascent (for pitch, cut-off commands, etc)


To conclude, I will try to later include here (not sure if today) a new preview, probably showing the integration with francisdrake's Orion MPCV - which is the most compatible in terms of mass vs my Orion – in key moments of the ascent.

After the feedback, I think that could then be in better conditions to start preparing what to release in a first fresh update.

Thanks,
António Maia

 

[Star Voyager]

I never liked the idea of encapsulating Orion in a fairing for the LAS. It adds weight, more complexity (jettison tower, shroud, then SM versus tower) and I personally think it looks ugly. I would think it would be simpler to just stick a tower on top of the CM and have an Apollo-style abort.

 

[K_Jameson]

I never liked the idea of encapsulating Orion in a fairing for the LAS.

Better aerodynamics (?)

 

[4throck]

"f possible, I would please like to read opinions about:

III.a) the LAS (integration) questions vs different Orion versions

III.b) .... what do you think about releasing a first update which would still strictly require external addons ...

III.c) Of those addons (for now focusing only in francisdrake's Orions) is there an order of preference for their integration as AresI payload?..."


I think that a standalone version, either using your orion meshes as mockups or just fairings + our beloved probe, would be great.

Not much different from what a test mission would be, with inert or mockup CM+SM.

At least I enjoy to have rocket families like that (we have Saturns, Titans, etc all launching dummy payloads.)

 

[K_Jameson]

By the way I like your Orbiter / FOI toys, some of them have interesting points of contact with my own development,

Well, the Jarvis S / Jarvis M duo is pretty much the same of Ares I / Ares V, with liquids instead solids. :thumbup:

 

[orbitingpluto]

The Stick configuration was gradually morphed for a bunch of reasons: first, the Orion weight problems; second and even more important, the extreme difficulty and costs for making the RS-25 engine air-startable. That, in the FOI fictional rocket science, was perhaps the main motive that lead to move from Jarvis M "Block I" to the "Block II" (moving the RS-25 from the second to the first stage, with ground starting instead on-air).

Returning to Ares I: they abandoned air-startable RS-25, then moved to J-2X (equally expensive, but at least air-startable from the beginning), but giving the much lower thrust (and ISP), the four-segments first stage was not sufficient anymore for matching the required specs, forcing it to move on the five segments (with others additional costs).
Similar problems (switch from RS-25 to RS-68, lower ISP, more fuel request, consequential enlargement of the core stage, more weight) has lead, in Ares V, the forced move to the five and a half segments (other costs, lower commonality with the Stick).

I'd do a disservice to you to not answer, so I'll just buckle down and give you an answer and not an excuse.

Exactly why I think Ares I was immutable was because it was a pet project, fostered from the top and forced downwards. All the technical problems that dogged it didn't really matter so long as the management people supporting it had the positions to fight for it and force it's continuance. As you point out and protest, Ares I got redesigned again and again, the other elements got compromised, all to obtain an ability that might have been gained at lower cost from a LV like the Delta IV Heavy. That switching horses wasn't an option is mostly

I'm with you in thinking Ares I was detrimental to Constellation, and should have been given the boot at some or or another, but without some element of alternate history(like instead of being cancelled, Constellation gets reorganized and managed by different people), I can't see Ares I going away.

-----------------------

Anyway, of the francisdrake Orions, I think the CEV-Orion-0i version fits in the best, being very rooted in the Constellation era. The newer Orion MPCV would be better feature-wise, but it's too new to look and act the part of a Constellation Orion.

-------------------

I never liked the idea of encapsulating Orion in a fairing for the LAS. It adds weight, more complexity (jettison tower, shroud, then SM versus tower) and I personally think it looks ugly. I would think it would be simpler to just stick a tower on top of the CM and have an Apollo-style abort.

Actually, Apollo was encapsulated during ascent, in what was called the Boost Protective Cover, essentially a fairing:

It fits close to Apollo and mimics it's shape, so I can imagine why you might have forgotten about it, or didn't notice it in pictures.