Centaur G/G Prime High Energy Upper Stage

[GLS]

Checked in a moved version. Amount is 3.5844 m.

OK, that's done. The only thing missing in the code are the correct offsets of the attachment points for the payload and CISS. I'm writing a small "help file" for this whole thing, and I crafted a scenario file for the VRM* mission and it's just waiting for the CISS G version. After this is done, I say the Centaur(s) are ready for release.


*) I still have to research this, but if the Magellan name appeared after the Centaur cancelation, I think our Centaur should launch the Venus Radar Mapper, as it wasn't guaranteed that it would be called Magellan. :2cents:

Update: scratch the phrase above, VRM was already known as Magellan in early 1986, so it's Magellan that flies in the Centaur.

---------- Post added at 02:52 PM ---------- Previous post was at 12:57 PM ----------

Initial Centaur reference file committed (still incomplete). Change/update as necessary.

 

[DaveS]

New CISS nearly done. The only things left are the propellant disconnect panels on the DA along with the avionics boxes and the addition of the O2 Mission Kit ducts as well as final texturing of the Mission Kit ducts.

If desired I could check in what I have right now (minus the Mission Kit) so that work on the animations can begin.

 

[GLS]

I just noticed that we're way overweight on the Centaur+CISS+payload, as the shuttle can't get into orbit using the Death Star scenarios. The complete payload is about 80000lbs... so about 15000lbs above what it should be. Part of the excess mass comes from the Carina vessel I used to simulate the probes, it's 5000kg and the Galileo was under half that. So that acounts for about 5500lbs... meaning the Centaur and/or CISS are overweight.

While we are on this subject, how about creating a "default payload" vessel, completely based on the Carina vessel and having a mass of 1000kg or so, to put atop the Centaur? That way it makes sense having the Centaur scenarios, as we can launch something.

 

[DaveS]

These are various mas tables that I have been to dig up:

Centaur G Technical Description, Feb 1982:

Centaur G Prime Technical Description, Jan 1984:

Final Environmental Impact State for the proposed Centaur Upper Stage for use with the Space Transportation System, March 1985:

Centaur G Prime Technical Description, Jan 1984:

A High Energy Stage for the National Space Transportation System, Oct 1984:

 

[GLS]

Wow, there are numbers for all tastes. I'll go with the March 1985 ones, as they are the most recent.

 

[DaveS]

Well, one thing with the mass is that there is no code that adds the total mass of the Centaur/payload to the CISS total mass in-sim. I just checked this by adding/reducing the propellant in the Centaur G Prime using the Scenario Editor and there was no mass difference in the orbiter.

So this fact impacts the performance of the shuttle as right now it only sees the CISS mass. Not the CISS+Centaur+payload total masses as it should.

 

[GLS]

OK, so I did my math and came up with these numbers for the G Prime (in pounds):
>> G Prime
tot
51750 (50450 galileo)
dry
6500
rl10 prop
45000 (43830 (97.4%) for galileo)
acs prop
250 (120 (48%) for galileo)
>> CISS G Prime
8900 (w generic s/c support)

which give a total upmass for the Galileo launch of 64884lbs, under de 65K limit (which we probably can't do ATM anyway), so I'm happy.
And for the G, I used the numbers above and modified then using the mass ratios between the stages from the Oct. 84 and Feb. 82 tables:
>> G
tot
39450
dry
7150
rl10 prop
32100
acs prop
200
>> CISS
8450 (w generic s/c support)

So, using fully tanked Centaurs, the available upmass would be 4350lbs for the Gprime and 17100lbs G. Now I still have to see if these numbers work in orbiter.

Well, one thing with the mass is that there is no code that adds the total mass of the Centaur/payload to the CISS total mass in-sim. I just checked this by adding/reducing the propellant in the Centaur G Prime using the Scenario Editor and there was no mass difference in the orbiter.

So this fact impacts the performance of the shuttle as right now it only sees the CISS mass. Not the CISS+Centaur+payload total masses as it should.

You are using the branch version of the shuttle, right? I think SiameseCat updated the mass code in the trunk and the payloads are added correctly now, but I have to check it to be sure.
If there are no complaints about the numbers above I'll go try them now.

---------- Post added at 09:54 PM ---------- Previous post was at 09:48 PM ----------

BTW, DaveS how far along is the CISS G mesh? If it doesn't have any "wrong parts" and it's just missing stuff, could you upload it? It's just so we have something there to would allow testing of the Centaur G.

 

[DaveS]

You are using the branch version of the shuttle, right? I think SiameseCat updated the mass code in the trunk and the payloads are added correctly now, but I have to check it to be sure.
If there are no complaints about the numbers above I'll go try them now.

I'm using the ShuttleCentaur branch. And by default attachments do not add the mass of any attached children. That has to be done by actual custom coding. The Shuttle Centaur in the trunk is still using SC3, not the our custom modules.

These are the ini files:

CentaurG_Prime.ini:

[CONFIG]
MeshName = SSU\CentaurG_Prime
Size = 10
Empty_Mass = 5166 ; CENTAUR DRY MASS (2605 kg) + SPACECRAFT SUPPORT SYSTEM MASS (2561 kg)
Fuel_Mass = 21088.65 ; MPS (20838 kg) + HYDRAZINE (22.65 kg) + HELIUM (1 kg) + OTHER (227 kg)
Isp = 4379.184
Main_Thrust = 73400
Retro_Thrust = 0
Hover_Thrust = 0
Attitude_Thrust = 324
Cross_Section = (26.07,25.9,14.52)
PMI=(6.74,6.75,2.20)

[EX_MAIN_0]
OFF=(-0.785,0,-4.5)
DIR=(0,0,-1)
LENGTH=4
WIDTH=1

[EX_MAIN_1]
OFF=(0.785,0,-4.5)
DIR=(0,0,-1)
LENGTH=4
WIDTH=1


[PARENT_ATTACH_0]
NAME = Payload
POS = (0,0,3.38)
DIR = (0,1,0)
ROT = (0,0,-1)
ID = "XS"
RANGE = 0.3
LOOSE = 0

[CHILD_ATTACH_0]
NAME = CISS
POS = (0,0,-2.5)
DIR = (0,1,0)
ROT = (0,0,-1)
ID = "XS"
RANGE = 0.3
LOOSE = 0

CISS_CentaurG_Prime.ini:

[CONFIG]
MeshName=SSU\CISS_CentaurG_Prime
Size=10
Empty_Mass=7212.7 ; CISS Total mass 5899.0 kg + Orbiter mounted items 1313.7 kg
Fuel_Mass=0
Isp=0
Main_Thrust=0
Retro_Thrust=0
Hover_Thrust=0
Attitude_Thrust=0
Cross_Section=(30.30,31.63,14.41)
PMI=(6.56,6.86,2.44)

[CHILD_ATTACH_0]
NAME=PLB
POS=(0,-2.35,0.5)
DIR=(0,-1,0)
ROT=(0,0,1)
ID="XS"
RANGE=0.3
LOOSE=0

[PARENT_ATTACH_0]
NAME=Centaur
POS=(0,-0.03,-1.16)
DIR=(0,1,0)
ROT=(0,0,-1)
ID="XS"
RANGE=0.3
LOOSE=0

[ROBOTIC_ARM]
JOINT_0_NAME="Deployment Adaper"
JOINT_0_SEQ=0
JOINT_0_RANGE=(0,45)
GRAP_SEQ=5
GRAP_ATTACH=0

[ANIM_SEQ_0]
INIT_POS=0
DURATION=58

[ANIM_SEQ_1]
INIT_POS=0
DURATION=58

[ANIM_SEQ_2]
INIT_POS=0
DURATION=58

[ANIM_SEQ_3]
INIT_POS=0
DURATION=58

[ANIM_SEQ_4]
INIT_POS=0
DURATION=58

[ANIM_SEQ_5]
INIT_POS=0
DURATION=58

[ANIM_COMP_0]
; Deployment Adapter
SEQ=0
GROUPS=30,
RANGE=(0,1)
ROT_PNT=(0,-0.04,-2.12)
ROT_AXIS=(-1,0,0)
ANGLE=45

[ANIM_COMP_1]
; GOX vent line segment 1
SEQ=1
GROUPS=6
RANGE=(0,1)
ROT_PNT=(-1.77,-0.47,-2.12)
ROT_AXIS=(-1,0,0)
ANGLE=45
PARENT=0

[ANIM_COMP_2]
; LOX fill/drain line segment 1
SEQ=2
GROUPS=13
RANGE=(0,1)
ROT_PNT=(-1.58,-0.66,-2.17)
ROT_AXIS=(-1,0,0)
ANGLE=45
PARENT=1

[ANIM_COMP_3]
; GH2 vent line segment 1
SEQ=3
GROUPS=25
RANGE=(0,1)
ROT_PNT=(1.77,-0.47,-2.12)
ROT_AXIS=(-1,0,0)
ANGLE=45
PARENT=2

[ANIM_COMP_4]
; LH2 fill/drain line segment 1
SEQ=4
GROUPS=18
RANGE=(0,1)
ROT_PNT=(1.58,-0.66,-2.17)
ROT_AXIS=(-1,0,0)
ANGLE=45
PARENT=3

[ANIM_COMP_5]
SEQ=5
RANGE=(0,1)
TIP_1=(0,-0.03,-1.16); POS
TIP_2=(0,-1.03,-1.16; DIR
TIP_3=(0,-0.03,-2.16); ROT
ROT_PNT=(0,-0.04,-2.12)
ROT_AXIS=(-1,0,0)
ANGLE=45
PARENT=4

---------- Post added at 11:07 PM ---------- Previous post was at 10:55 PM ----------

BTW, DaveS how far along is the CISS G mesh? If it doesn't have any "wrong parts" and it's just missing stuff, could you upload it? It's just so we have something there to would allow testing of the Centaur G.

Won't that break the compatibility between the G and G Prime? The new CISS is vastly different from the old CISS.

---------- Post added at 11:12 PM ---------- Previous post was at 11:07 PM ----------

An early version of the new CISS for the Centaur G has been checked in. Do note it's very rough. I haven't done any real alignment checks at all so things might be off.

 

[GLS]

Won't that break the compatibility between the G and G Prime? The new CISS is vastly different from the old CISS.

---------- Post added at 11:12 PM ---------- Previous post was at 11:07 PM ----------

An early version of the new CISS for the Centaur G has been checked in. Do note it's very rough. I haven't done any real alignment checks at all so things might be off.

Thanks! It's just so something shows up in the screen when loading the CISS/Centaur G.

 

[DaveS]

Thanks! It's just so something shows up in the screen when loading the CISS/Centaur G.

Couldn't the current G Prime CISS be used as a stand in?

 

[GLS]

Couldn't the current G Prime CISS be used as a stand in?

Hmm probably. But this way there's no changing names and copying files. Don't worry, I know it's WIP .

 

[DaveS]

Another thing is rotating the Centaurs so that they're oriented the correct way when attached to the CISS DA. Currently they're 90° off due to the rotation.

 

[GLS]

Another thing is rotating the Centaurs so that they're oriented the correct way when attached to the CISS DA. Currently they're 90° off due to the rotation.

It was all correct on Sunday: mesh, thruster coordinates and attachment rotation (the position still needed some fine tuning)... and now the G Prime mesh is rotated (the G is correct)... could you check if you uploaded an un-rotated Centaur G Prime mesh?
(Also, I fixed 2 typos in the texture paths inside the Centaur G mesh)

On the Centaurs/CISS masses... we're not making the guided MECO by 100m/s or less. And this is using the new SSUDefaultPayload (which is nothing more than 1000Kg carina satellite), which means we're in the red for both probes (I also tried the Ulysses launch with 400kg instead of 1000 and still no joy). Any sugestions?

Also, I can confirm the payload mass is added to the shuttle.

 

[DaveS]

Also, I can confirm the payload mass is added to the shuttle.

I can't, at least not the ShuttleCentaur dev branch. A for what it is worth, I don't see any code in either the CISS or Centaur that adds the child's current mass to the parent's current mass. And a check of the Object Information dialog confirms this. When checking the CISS the only mass reported is the mass of the CISS itself (7212.7 kg).

Screenshot:

 

[GLS]

I tested the trunk shuttle with the Centaur and a MASSIVE payload, attached to the Centaur, and it barely got off the ground, so I have no concerns about the mass on the shuttle.
But you're right about the mass of the Centaur after separation, as the payload doesn't affect its performance. I'll try to fix that, but I see little point in adding mass to the CISS... it probably would harm the existing shuttle code, as it would add some mass twice. The way I see it, it makes sense to add the payload mass to the Centaur when it separates from the CISS.

 

[DaveS]

I tested the trunk shuttle with the Centaur and a MASSIVE payload, attached to the Centaur, and it barely got off the ground, so I have no concerns about the mass on the shuttle.
But you're right about the mass of the Centaur after separation, as the payload doesn't affect its performance. I'll try to fix that, but I see little point in adding mass to the CISS... it probably would harm the existing shuttle code, as it would add some mass twice. The way I see it, it makes sense to add the payload mass to the Centaur when it separates from the CISS.

Can you confirm that this is your SSU_CentaurGPrime.cfg in the trunk?

; === Configuration file for SSU_CentaurG_Prime ===
ClassName = SSU_CentaurG_Prime
Module = Spacecraft3

;MeshName = SSU\CentaurG_Prime
;Size = 8.0

;Mass = 2739.6 ; empty mass [kg]
;MaxFuel = 20250  ; max fuel mass [kg]
;Isp = 4379.184        ; fuel specific impulse [m/s]

;MaxMainThrust = 146520
;MaxRetroThrust = 0
;MaxHoverThrust = 0
;MaxAttitudeThrust = 5e2
;COG_OverGround = 2.0
;CrossSections = 26.07 25.9 14.52
;Inertia = 6.74 6.75 2.20

; === Attachment specs ===
;BEGIN_ATTACHMENT
;P 0 0 -2.5  0 1 0   0 0 -1 XS: To CISS Deployment Adapter
;C 0 0 3.38  0 -1 0  0 0 1  XS; Payload Attach Fitting attachment point
;END_ATTACHMENT

And this is the SSU_CISS_CentaurGPrime.cfg:

; === Configuration file for SSU_CISS_CentaurG_Prime ===
ClassName = SSU_CISS_CentaurG_Prime
Module = Spacecraft3

As you can see, both of them is using SC3. There the mass of the Centaur is simulated as a propellant tank on the CISS. This is "propellant mass" is added to the total mass of the CISS which SSU sees as the payload and adds to its total mass.

But in our custom CISS/Centaur modules, nothing like this is happening. Instead SSU only sees the CISS and adds only the CISS "empty mass" to its total mass.

So over 20 tons of mass is not added to SSU's total mass. In fact, I just did a test launch with the propellant mass of the G Prime increased by 10x and there was no issues at all. By all means, that mass would have caused serious problems, yet it didn't.

This will be an issue once the ShuttleCentaur branch is merged with the trunk and we're using our own code, not SC3.

As I wrote earlier: The default and standard behavior of the attachment system is that the attached child's physical properties (PMI, CS and mass) is not added/subtracted from the parent's physical properties. This is up to the developer to implement in his/her own code. I have dealt with attachments long enough to know this by heart.

 

[GLS]

I'm not using SC3 for some time now. I've compiled the trunk, then switched over to the ShuttleCentaur branch, and then I'm very careful not to hit F7 in visual studio (full compilation), but I only compile the CISS and Centaur projects individually. This way I can use the latest "shuttle" from the trunk and the latest centaurs from the branch. And using this setup (which makes the shuttle look awful as textures changed in the meantime, but doesn't matter for testing) the mass of the carina/SSU_DefaultPayload makes a difference in the performance during launch.
I've just finished the payload mass addition to the Centaur, and I'm just running some tests to make sure it works properly before committing it.

---------- Post added at 03:46 PM ---------- Previous post was at 03:31 PM ----------

Bad news: I just found what appears to be a bug in the shuttle mass code: when the Centaur is separated, its mass (and the payload) is not subtracted from the shuttle total.
Good news: the new code for the Centaur mass works, the payload mass is added to the Centaur when it is in free flight, and subtracted when the payload separates.

---------- Post added at 04:13 PM ---------- Previous post was at 03:46 PM ----------

I'm not going to commit the "Centaur mass code", as we have to decide this mass addition conundrum first. Options:
1) each vessel adds the mass of their child(s), and we remove the recursive attachment search from the shuttle mass code;
2) we keep the recursive search in the shuttle and each child adds nothing while it isn't in free flight, and we must trigger the payload mass update in the shuttle somehow (it isn't "continuous" at the moment, only when something separates from the shuttle itself);
3) similar to 2, but we make the payload mass update in the shuttle "continuous" (not sure about performance).

 

[DaveS]

I'm thinking 3 is the best as we'll need it once Centaur aborts are implemented.

 

[Urwumpe]

I would say a mixture of 2 and 3.

Only update the masses, when the Centaur masses change. If they change every timestep, we need to update them every timestep.

Make it possible to quickly disable this code (ideally by #if defined(SSU_MASS_UPDATE) ... #endif ) so, that we have no later effort for removing this code for "Orbiter 201x", when the new attachment handling arrives. After all, its easier to make the code removable now, than to remove it later.

 

[GLS]

I'm thinking 3 is the best as we'll need it once Centaur aborts are implemented.

Yeah I'd try 3 first, and if that costs too much performance try 2, and 1 would be my last choice.
Going back to the trunk, as it looks like something is not right with the MFD button labeling... :facepalm:

---------- Post added 03-04-15 at 12:29 AM ---------- Previous post was 03-03-15 at 04:46 PM ----------

DaveS, any reason why you when back on the Centaur and CISS code in r1981?