Space Shuttle Ultra 1.25 Revision B development

[SiameseCat]

In the SVN repository, it's Doc/Space Shuttle Ultra/SSU Ops Manual V1.XX Rev B.pdf

 

[DaveS]

Page 8, Camera views: It should be added that the PLB cameras can be moved using Alt+arrow keys.

Pages 16 and 17 needs to have information on the mission files and scenario files added, currently they're blank and empty.

 

[Urwumpe]

If we're targeting a release April 12, we should probably update the documentation. It would be nice if everyone had a look at the latest version of the manual and we decide what information needs to be added.

I am not sure we should hit this years April 12, though the chances aren't that bad. But like the real STS... better scrub launch seconds before lift-off, than launch with a bad engine.

 

[DaveS]

STS-11A would be our next release.
STS-12A would be (STS-X2X = Launches from Vandenberg) would be the first hypothetical extension pack.

How would this work considering that launches from VAFB is already possible? Are we going to leave out VAFB from the release pack and include it later?

 

[Urwumpe]

How would this work considering that launches from VAFB is already possible? Are we going to leave out VAFB from the release pack and include it later?

LOL, no. We already have VAFB in a pretty far finished state now and can include it now. But any improvements to VAFB would be a perfect candidate for the X2-X series.

I know that Slick-6 is a pretty tough candidate there, since it is both historically existing and still an alternative history component, since we never had even just a FRF on it.

 

[GLS]

About the SSME tailoff I did some runs and it looks like, on your "average mission", each engine gives around 11 m/s dV at 67%. So 33 m/s would be the offset to take into account, not sure if that should go to the AscentGuidance or the MECOtool....

Another thing I noticed in these runs, and also before, is that SRB sep is about 10 Km lower and 100 m/s slower that on the real thing. Don't think it's a show-stopper for a release in the next few days/weeks, but it should be checked for a release down the road. Maybe later today I'll compare the SRB thrust with somethings I have.

And on the documentation for the MPS/SSMEs there's not a lot to say at the moment. Right now the MPS Engine Power and EIU switches are one-way, i.e. after you shutdown something, turning it back on won't do nothing (looks like it's not exactly like that in the real thing, but there's not enough info to say for sure).

 

[Urwumpe]

Well, I already have Netbeans 7.3 installed and configured... Only VC++ and TortoiseSVN are missing. With Netbeans, I could already start the project for a new Mission Planning tool here.

Problem: It would be a new feature before release and that is bad. But it could fix the trouble with MECOCalc. And I could only do a preliminary version with just the MECO calculations before April 12 is reached.

 

[DaveS]

Well, I already have Netbeans 7.3 installed and configured... Only VC++ and TortoiseSVN are missing. With Netbeans, I could already start the project for a new Mission Planning tool here.

Problem: It would be a new feature before release and that is bad. But it could fix the trouble with MECOCalc. And I could only do a preliminary version with just the MECO calculations before April 12 is reached.

I think locking us in to a date like this is bad. It could lead to bad cases of schedule pressure. The main thing is that we make good releases, not buggy and incomplete rushed releases on a specific date. I think we'll be forgiven if the date slips but the release is good.

 

[Urwumpe]

I think locking us in to a date like this is bad. It could lead to bad cases of schedule pressure. The main thing is that we make good releases, not buggy and incomplete rushed releases on a specific date. I think we'll be forgiven if the date slips but the release is good.

I think that I already said that April 12 should be a coarse goal, no deadline. And a bit of pressure isn't bad. It helps staying focussed.

 

[GLS]

SRB sep is about 10 Km lower and 100 m/s slower that on the real thing.

Actually it's 100m/s faster (I was looking at the wrong speed :facepalm, but the altitude error is that. The SRB thrust looks +/- ok, might be a little high at some points (80-110s). Also looked at the SSMEs and found a tiny error in max thrust but nothing that would make a big difference. Guidance also looks ok.
To me it kinda looks like it's accelerating too fast, and guidance keeps pitching down leading to a higher speed and lower altitude.
I think I can find time tomorrow to lower the SRB thrust at those points and see what it does, if it's not that then the vehicle mass is to blame.

 

[DaveS]

Actually it's 100m/s faster (I was looking at the wrong speed :facepalm, but the altitude error is that. The SRB thrust looks +/- ok, might be a little high at some points (80-110s). Also looked at the SSMEs and found a tiny error in max thrust but nothing that would make a big difference. Guidance also looks ok.
To me it kinda looks like it's accelerating too fast, and guidance keeps pitching down leading to a higher speed and lower altitude.
I think I can find time tomorrow to lower the SRB thrust at those points and see what it does, if it's not that then the vehicle mass is to blame.

Well, we're currently only simulating one of the lightweight orbiters(103, 104 and 105). 102 and 099 ere significantly heavier than the "production" orbiters.

Also, ET mass could play a role depending on which mission you're looking at, as could the fact that we currently don't have any payloads.

 

[SiameseCat]

The other thing that could potentially affect things is how 'high' the CG of the entire stack is. The SSMEs are gimballed through the stack CG, so if the CG is too low, some thrust will be lost.

 

[DaveS]

The other thing that could potentially affect things is how 'high' the CG of the entire stack is. The SSMEs are gimballed through the stack CG, so if the CG is too low, some thrust will be lost.

Well, I did discover that the null position of the SSMEs on the mesh was located in the wrong locations and in the wrong angles.

According to the STS News Reference Manaul, the null position of the center engine is +16° above the X-axis in pitch, 0° in yaw.

For the left and right engines, the null positions are 10°s in pitch and 3.5°s in yaw. Here's the round up for SSU:

Center engine: 12° pitch vs 16° pitch
Left and Right engines: 9.2° pitch, 2.5° yaw vs 10° pitch, 3.5° yaw.

So as you can see, the angles are off.

 

[SiameseCat]

The null position of the SSME in the mesh doesn't matter. What's important is the position of the SSME thruster definitions:

const VECTOR3 SSMER_REF = _V(1.458, -0.194, -11.7875);
const VECTOR3 SSMEL_REF = _V(-1.458, -0.194, -11.7875);
const VECTOR3 SSMET_REF = _V(0.0, 1.945, -10.76250);

Do you know if these are correct?

 

[DaveS]

The null position of the SSME in the mesh doesn't matter. What's important is the position of the SSME thruster definitions:

const VECTOR3 SSMER_REF = _V(1.458, -0.194, -11.7875);
const VECTOR3 SSMEL_REF = _V(-1.458, -0.194, -11.7875);
const VECTOR3 SSMET_REF = _V(0.0, 1.945, -10.76250);

Do you know if these are correct?

They are not. Here's the values I use:

Atlantis.cpp

void Atlantis::CreateSSMEs(const VECTOR3 &ofs)
{
	if(!bSSMEsDefined) {
		th_main[0] = CreateThruster (ofs + SSMET_REF, _V(0.0, -0.2447, 0.9674), ORBITER_MAIN_THRUST, ph_tank, ORBITER_MAIN_ISP0, ORBITER_MAIN_ISP1);
		th_main[1] = CreateThruster (ofs + SSMEL_REF, _V(0.065, -0.2447, 0.9674), ORBITER_MAIN_THRUST, ph_tank, ORBITER_MAIN_ISP0, ORBITER_MAIN_ISP1);
		th_main[2] = CreateThruster (ofs + SSMER_REF, _V(-0.065, -0.2447, 0.9674), ORBITER_MAIN_THRUST, ph_tank, ORBITER_MAIN_ISP0, ORBITER_MAIN_ISP1);	
		bSSMEsDefined = true;
		//thg_main = CreateThrusterGroup (th_main, 3, THGROUP_MAIN);
	}

void Atlantis::DefineSSMEExhaust()
{
	int i;

	SURFHANDLE tex_main = oapiRegisterExhaustTexture ("SSU\\SSME_exhaust");
  	for(i = 0; i<3; i++)
	{
		if(ex_main[i])
		{
			DelExhaust(ex_main[i]);
		}
		ex_main[i] = AddExhaust(th_main[i], 70.0, 3.0, 0, tex_main);
	}
}

Atlatis_defs.h:

const VECTOR3 SSMER_REF = _V(1.64812, -0.3, -14.58);
const VECTOR3 SSMEL_REF = _V(-1.64812, -0.3, -14.58);
const VECTOR3 SSMET_REF = _V(0.0, 2.4, -14.16);

 

[Urwumpe]

Is this the position relative to the origin of the Shuttle coordinate system or relative to the CoG?

 

[DaveS]

Is this the position relative to the origin of the Shuttle coordinate system or relative to the CoG?

The Orbiter mesh coordinate system.

 

[Urwumpe]

The Orbiter mesh coordinate system.

Remember that the position and directions of the SSMEs in Orbiter depend on the position of the CoG, which is sure as hell different to the CoG of the real one, since we don't do any CoG calculations yet.

 

[DaveS]

Remember that the position and directions of the SSMEs in Orbiter depend on the position of the CoG, which is sure as hell different to the CoG of the real one, since we don't do any CoG calculations yet.

As I wrote above: I changed the positions of the engines in the mesh, so I had to generate new positions and directions so that the exhaust rendering would line up in Orbiter.

 

[Urwumpe]

Still no problem, if they are the accurate positions. But still any effects of the thruster position on the trajectory have to consider that we use a wrong CoG position most of the time.