CEV Orion, 606 update

[Cale]

Hmm, downloaded the modules from Microsoft, ran the program, then re-installed version g but still get the same CTD. Think I'll stay with version f until I can figure this out.

 

[francisdrake]

If you still have problems, please try this runtime library:
http://www.microsoft.com/downloads/...34-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en

They are for the 2008 version (corrected the link on the previous page, too.)
Also I would like to know, if other user have experienced problems running this version.

 

[Urwumpe]

I have no problems here, but I have also VS2008Pro installed. The acceleration at lift-off is now significant lower, I have yet to find a good initial pitch over for a nice gravity turn.
(I know, I could calculate it. But thats only half the fun).

EDIT: I get a CTD in the "docked at ISS" scenario:

>>> ERROR: Missing texture: U_mmu.dds
>>>        [C:SourceOrbiterTexture.cpp / 781]
>>> ERROR: Missing texture: U_mmu.dds
>>>        [C:SourceOrbiterTexture.cpp / 781]
**** WARNING: Mesh not found: .MeshesCEV-OrionCEV-Orion-panel.msh
>>> ERROR: Missing texture: U_mmu.dds
>>>        [C:SourceOrbiterTexture.cpp / 781]
Finished initialising status
Finished initialising camera
Finished initialising panels
Finished setting up render state
>>> ERROR: Missing texture: PSLV-S1.dds
>>>        [C:SourceOrbiterTexture.cpp / 781]
**** WARNING: Mesh not found: .Meshes.msh

The bug report looks strange...

 

[FlyGirl]

I am getting the same CTD with the "CEV at ISS" scenario and the same log error messages as Urwumpe.

 

[Urwumpe]

The bug also takes place in the launch scenario, when you separate the second stage.

I have always stopped the launch scenarios lately when it was clear that the ascent was not working well.

 

[Adam]

I got the same bug but only in external view if I separate cev while in internal view orbiter is running normaly

 

[Cale]

Ok, re-downloaded the library files. A slight improvement: I can open up a scenario when in cockpit mode, but as soon as I switch views to either external or VC, I get a CTD.

Wonder if it has anything to do with the changes made to the VC?

Ah well, that's why it's a beta version, right?

Cheers,

Cale

 

[Cale]

BTW, any news how Mikey's doing with updating LaunchCEV?

 

[francisdrake]

Sorry folks, this version was a little more beta than it should have been.Forgot to add a mesh I was trying out, and the texture of the Ummu-spacesuit.I have corrected that and tested it in a clean Orbiter installation.Please re-download the 0g version again.

http://home.arcor.de/francisdrakex/download/CEV-Orion-0g.zip

Does someone know if Danstephs Ummu-SDK runs with VC++ 2008?It will not get linked, referring to missing external symbols.That could be because the Ummu lib is not properly recognized ...

 

[Urwumpe]

I think it runs, but the external missing symbols could come from incompatible compiler settings. I have not yet tried it... But I can make a test.

 

[francisdrake]

Got the MFD's and HUD running in the virtual cockpit! Everything still looks a little crude, but the code seems to work:

 

[Cale]

Just wondering if it's normal for the thrusters to always be firing when holding in either prograde or retrograde mode.

BTW, the VC looks awesome.

Cheers,

Cale

 

[FlyGirl]

Looking great, can't wait to try it out.

Got the MFD's and HUD running in the virtual cockpit! Everything still looks a little crude, but the code seems to work:

 

[ryan]

You rekon they have designed a cockpit for the real Orion.

 

[Kyle]

All I can say is, Awesome!

 

[simcosmos]

Hello Franz (all)

Hope you do not mind a few extra comments where will also make comparisons with my own AresI performance implementation preliminary data (by using Vinka's multistage2.dll)


a) Franz, have you implemented a thrust curve on '0g' version? Just asking because it seems that still have a burn time lower than expected (and the g felt during SRB phase are a bit high, same for maxQ!).

Back to burn time comments: ~105s or so is similar to what have implemented in my currently in-development updates for Vinka's multistage2.dll INI versions of AresI, except for a *little* detail: the SRB curve is being implemented here via thrust commands on a guidance file so that the 'burntime' in the INI (which is related with the time it would take to burn SRB's useable fuel if at maximum thrust) becomes an *operational* burn time closer to ~126s (with the thrust curve being similar to what have provided in a previous post).



b) Will share next a few ascent notes, ISS inclination (and remembering that these approximated preliminary numbers are from an updated / work in progress implementation of AresI with multistage2.dll / ~926409Kg total AresI-CEV mass):

~40s - Mach1 – 6.3Km alt

~50s – maxQ – 33.6 to 34.6KPa (~723psf)

~126s: SRB separation at ~60Km altitude, ~Mach5.7, ~820m/s VSpeed, 20 degrees pitch, instant apogee slightly lower than 100Km altitude. SRB retro motors burn would then happen (lowering apogee + building distance from US; this retro burn is not currently simulated here) + US separation solids would also burn for ~3.7s and after ~0.5s to 1s coast from SRB separation.

~131s: ~5s after SRB separation, J-2X is at 100% thrust

Next comes LAS separation + release of the CEV SM covers: this needs to happen within ~30s after J-2X being at full thrust (else, depending of mission considerations, there might happen noticeable performance hits). If needed, the time to release these items can be closer to ~5s to 10s after J-2X ignition (again, depending of how badly performance after SRB sep might or not be needed, for some specific missions and under a few extra assumptions).

Moving on: for ISS missions, I'm currently making LAS release to happen at ~165s, at ~87Km altitude / Mach7.5 or so.

After releasing LAS + SM covers, the plan here is to make quick transition from 20 degrees pitch to ~32 degrees and then slowly lower to ~30 degrees. This should be enough to reach ~125Km altitude first apogee and to compensate for gravity losses in order to start reducing pitch in the bottom of the 'gravity descent' to whatever values needed for –20 x 185Km injection goal (with ~1.7% to 1% propellants inside US where making here total propellant amount to be ~139.67t).

Note: would recommend not going lower than ~106Km altitude when being in the bottom of the 'gravity descent', after reaching the first apogee (this is related with eventual abort considerations for CEV).



c) Franz, if having the opportunity (later occasion, not sure when): I might try to share a screenshot (ISS inclination) from Virtual Mission Control's AresI ascent telemetry or might provide any extra data, if wanting to have an extra estimative for AresI performance implementation.

Meanwhile: could share the ISS pitch program, at least for the SRB phase, but... such program is closely related with my masses / performance implementation (the results would be different with other assumptions).

Last but not least: using 270 as AresI heading at the pad (this means heads down with almost zero roll for Exploration missions and acceptable roll amplitude - lower than STS - for ISS).

António

 

[francisdrake]

Antonio,
thanks for the detailed data!
Tweaking the SRB thrust curve currently looks like this:
54 sec, Mach 1, alt 7.4 km
77 sec, max Q, 38 kPa
130 sec, MECO, alt 45 km, v 1,7 km/sec.

It looks like the initial accelleration of my addon is too slow, but the thrust is set to 15.333 MN,
so unless I goofed up adding the various weights I don't know why it starts so slow.
Will have a look at the weight numbers tomorrow.

Orbit insertion happens here currently with around 2.4% fuel left, which is a little bit high, but leaves a convenient margin for not-so-perfect orbit alignment. This may reduced slightly in the future.

 

[simcosmos]

Differences between our results are due to non-equal masses breakout, ascent procedures, performance numbers and perhaps also slightly due to performance implementation constraints (custom dll vs multistage2.dll) or other performance implementation strategies.

EDIT / extra note: I'm not increasing thrust / ISP values for playability, not needed for now, under some specific assumptions (mass numbers control) for the whole AresI-Orion - as an integrated system - although I'm trying to implement some extra (mass) margins (adding mass to launcher) and then try to have a first order estimative for what could be the maximum effective payload that can end up with for ISS / Exploration missions (where defining effective payload as just the CEV spacecraft itself, the CM+SM).


Focusing in the 5 segment SRB, I'm using 15616776.4129 N as the maximum thrust entry in the associated multistage2.dll INI and then use the guidance program to extend the 'burtime' coded in such INI (that burntime = time to burn usable fuel if at max. thrust) by implementing the thrust curve in terms of percentage of such maximum value, being that:


a) have made the thrust to be ~98.18% (15.33MN) of that max. value during the first seconds (liftoff)
b) then reach first maximum thrust: ~98.88% (at 21.56s)
c) for the second maximum, use ~93.82% (at 78.81s)

(beyond using intermediate %values, between these two maximums and after second maximum, related with a thrust curve's shape similar to the one displayed in previous post)

But please have in mind that I'm not sure if the approach is correct or not: this is just and only something that have implemented for multistage2.dll (together with other tweaks) and which seems to return expected performance results for solid motors simulations (4 seg. SRB + 5 seg. SRB), at least if looking at it as a rough first order approach and, in this specific case, when comparing with some past known AresI (andV + STS too) ascent info.

António

 

[francisdrake]

With the help of DanSteph I got the UMMU working (the basic functions first).
The pic shows the first EVA of two UMMU astronauts

 

[Brad]

With the help of DanSteph I got the UMMU working (the basic functions first).
The pic shows the first EVA of two UMMU astronauts

IMPRESSIVE! Love the work you have done.