SSU Development Thread (2.0 to 3.0)

[GLS]

We do have panel R4 as well L4 on the CDR side. Here's a screenshot of R4:

Yes, the panel is there, but is not "coded". I would need coordinates that I don't have access to. The only thing I can get is the "Ctrl+3" coordinates...
About the view, that looks like a very good angle. Can another "AltGr+Arrow" position/whatever be added to the PLT position with that angle?

 

[GLS]

Quick question: is there any problem with the UpdateSSMEGimbalAnimations function? It's there but not being called by anybody. I "plugged it in" and it seems to move the SSMEs well... (trying to do the MPS dump repo)

 

[DaveS]

Can someone remind me what units the throttle down/up parameter takes?

 

[GLS]

Are you talking about the 1º stage "bucket"?

 

[DaveS]

That's the one. I'm trying to adjust it yield more realistic Q values. According to Bill Harwood's mission preview of STS-121, the max Q value for STS-114 was 695 PSF (33.3 kPa). This is all in an effort to debug the ascent performance mystery.

My current theory is that the reason we're over-performing during ascent for the early missions is that we're flying the Performance Enhancement (PE) ascent trajectory that was developed for ISS.

Another thing is the throttle bucket band: Currently it sits at 72-104 when back in the day it was 65-104.

 

[GLS]

The throttle commands are commanded just like attitude in 1º stage, that is "at X Vrel do Y throttle". That "table" (attitude as well) might be modified twice: during the countdown (the DOLILU) due to winds, and in flight by the "Adaptive Guidance" algorithm, that measures the time it takes to reach a certain velocity, and based on that determines if the SRBs are "cold" or "hot". If they are cold the pitch profile is lowered and the bucket is decreased, and if they're hot it's the other way around.
Currently the throttle "update" is simulated, but it's based on "recent" numbers. The AGT parameters are I-loads (or in the SSU world, mission file parameters), but as there's no more data to choose from they are constant for now. The units should be fps and % throttle, but currently is m/s... I'll correct that sometime in the future.
One thing we really need is a program to create the mission files with all the values we need. That way we could choose the different profiles with just a click in a radio button, and it would output the correct values for pitch/throttle/AGT/roll program speed/MECO/etc... Yes, we would need to know those values, but this way it would be a lot easier to have all of the parameters "in the same page".

Another thing probably worth looking into: SRB empty mass and pressure/thrust. If you look at the early missions here, there's some kind of code designation to the SRMs. Let's take STS-7 "007LW(SPM)" and STS-8 "008LW(HPM)": The "SPM" and "HPM" I'm pretty sure mean "standard pressure motor" and "high pressure motor", as I've read somewhere that STS-8 was the 1º mission with high pressure SRMs (Rogers Commission report maybe?). The LW I'm not sure, but looking at the other missions it seems (and this is all a wild guess) to be "light weight". There's also SW (standard weight), MW (medium weight), WW (welter weight), QW (quarter weight) and a mixture of some of those.

 

[SiameseCat]

The throttle bucket is defined in the mission file using the "ThrottleDown" and "ThrottleUp" values (both are velocities in fps). At the moment, the SSMEs throttle down to 72%, which is hardcoded.

 

[DaveS]

Another thing probably worth looking into: SRB empty mass and pressure/thrust. If you look at the early missions here, there's some kind of code designation to the SRMs. Let's take STS-7 "007LW(SPM)" and STS-8 "008LW(HPM)": The "SPM" and "HPM" I'm pretty sure mean "standard pressure motor" and "high pressure motor", as I've read somewhere that STS-8 was the 1º mission with high pressure SRMs (Rogers Commission report maybe?). The LW I'm not sure, but looking at the other missions it seems (and this is all a wild guess) to be "light weight". There's also SW (standard weight), MW (medium weight), WW (welter weight), QW (quarter weight) and a mixture of some of those.

According to the Jenkins' book, there have been four distinct types of cases used for the SRMs:

STD, used on STS-1, 2, 3, 4, 5, 8, 9
LTWT, used on STS-6, 7: Walls 0.003 to 0.005 inches thinner saving 5k lbs
MWC, used STS-41B, 41C, STS-51G, STS-51F: Walls 0.001 to 0.002 inches thinner.
LWC used on all other STS prior to 26R: Walls 0.002 to 0.004 inches thinner saving 4k lbs. RSRM uses the same cases but modified incorporate post-STS-51L changes such as capture feature, third o-ring and joint heaters.

HPM is short for High-Performance Motor which first flew on STS-8. Prior to that, Standard Performance Motors (SPMs) were used. They only put out a maximum of 2.8 million lbf thrust rather than the 3.0 million lbf thrust of the HPMs.

 

[GLS]

So I'll just answer my question then. :lol:
Apart from a little bug in the animation of ME-3 (there's some aft translation in the nozzle when it gimbals), it seems to work well.

After checking that, I went and did a makeshift ATVC (and it's SOP), to command the gimbals, until Urwumpe finishes the ATVC/gimbal stuff he is working on. And it got this to do the pre-launch gimbals and mps dump/entry stow and then lowering the nozzles for the drag chute, blah blah... all with some guesses about the angles, because I can't find any real position data.
And because I'm not sure the current implementation of the SSME thrust vector control is correct (it works well, but looks like it might move beyond the actual limits), I rewrote some of the code that controls the vector directions during ascent.
And then I found out that I don't know as much algebra as I thought I did. :facepalm:
Not sure if I'm doing it wrong or if what I want to do is "impossible":
1) calculate the SSME thrust vector that gives 0 moment and calculate the angles to the axis, and use them in AscentGuidance to do the guidance math;
2) take the output from AscentGuidance and apply a "correction" for the SSME install position, i.e. the angles between the SSMEs 0º gimbal and the axis (the 16º/0º and 10º/+-3.5º angles from the "literature"), and then another "correction" corresponding to the angles of the 0 moment for each engine;
3) take the resulting angles above and rotate the SSME install position vectors, thus getting the new thrust direction, then and do the gimbal animation.
Essentially I want to have the ATVC/actuators rotate the SSME install vector by whatever angle it is requested, in the corresponding actuator plane.
So basically the problem is that with only the center engine running it looks like it does everything well, but when I use one of the side engines, it can't control the vehicle (something is not correct)... and if you're wondering about controlling roll with just one engine, I did implement SERC , so the engines just do pitch and yaw in those cases.
In 1, I'm using pretty much the existing CalcSSMEThrustAngles() function, for 2 it's pretty much just sums and I use a modified version of CalcSSMEThrustAngles() to get the angles for each engine, and for 3 it's the same SetSSMEGimbalAngles() function, and of course I created 3 new vectors corresponding to the SSME install positions. In CalcSSMEThrustAngles() I tried changing the angle calculation from asin() to atan() and atan2() which makes more sense in my head and still no joy.
I think the problem might be the 2 sets of 2 rotations: one X and one Y to obtain the SSME install vectors (done outside orbiter) and then the 2 rotations for the gimbal. Not sure if this sequence is supposed to work...
:sos:

I understand that this is not *exactly* mps branch material, although somewhat related. If anybody feels I shouldn't be doing this, I'll stop it and move the proper mps stuff.

 

[SiameseCat]

Can you post/commit the code you have? As far as I can tell, what you've done looks fine. I think the existing gimbal angle calculations are slightly off (using atan/atan2 instead of asin is probably correct), but the angles are small enough that this shouldn't have a big impact).

 

[GLS]

Can you post/commit the code you have? As far as I can tell, what you've done looks fine. I think the existing gimbal angle calculations are slightly off (using atan/atan2 instead of asin is probably correct), but the angles are small enough that this shouldn't have a big impact).

OK, I'll upload the whole thing to the mps branch in a few minutes. I'll also upload 2 test scenarios I use for a quick launch (STS-1 T-45s and STS-126 T-1m).
The SSMEx_INSTALLED_NULL_POS consts where calculated in matlab using the formulas from the RotateVectorX()/RotateVectorY()/RotateVectorZ() functions (in that sequence). I did try a bunch of different ways to create those coordinates (there're commented out)... not really confident in those.
Basically any running engine config that isn't balanced in yaw -> bye bye control. And I'm not 100% confident it's doing the job perfectly in pitch as well.
The angles in the ATVC are not in line with the real convention, and SERC is not perfect as it fires the FxD thrusters (need better RCS implementation) and then makes the RCS unusable after MECO. Will fix those later.

---------- Post added 08-11-14 at 04:29 PM ---------- Previous post was 08-10-14 at 05:17 PM ----------

Another possible cause for the ascent over-performance could be a further difference in ET prop mass (on top of the already discussed 5400lbs in the MPS manifold). Just found out that the SSMEs use about 11700lbs from ignition to T0. If the ET prop mass we are using is the prop mass at liftoff, instead of the tanked mass, then we are flying with a lighter vehicle. Don't know if this is the case (will look at all this and work the ET after the ATVC stuff is out of the way), but I just wanted to put this here for info (and also so I don't forget it ).

 

[gattispilot]

I think it is outside my league of coding. Willing to help though

 

[GLS]

So I'm doing the "propellant revolution", and to begin I moved the ET tank to the Atlantis_Tank vessel, and have a "MPS manifold tank" that feeds the SSMEs, and that calls the tank to "use" it's propellant (which I decrease accordingly using SetPropellantMass()).
Then I run this, and the mass of the vehicle is not decreasing :facepalm: (and of course it fails to get into orbit), although in the ScenarioEditor I see the ET propellant mass decrease at the appropriate rate.
Orbiter bug, am I doing it wrong or can't be done this way?

---------- Post added at 01:36 PM ---------- Previous post was at 01:51 AM ----------

Did a little more digging and managed to "fix" the issue by calling the UpdateMass() function in Atlantis every time I do the "ET mass update". Not really intuitive the way the mass of attached vessels is managed in Orbiter but looks like it works now.

(I think this "episode" also applies to the Centaur, when we get that to do in-flight propellant dumps)

 

[GLS]

I think it is outside my league of coding. Willing to help though

Well, I would say right now we need coders... take a look in here, there's a lot of work still to do. I'm not the boss, but if you ask me, right now we need the "SSU Mission Toolbox" the most. That, along with some small changes in the architecture, would make it a lot easier to change vehicle configuration.

(Shouldn't these posts should be moved somewhere else?)

 

[gattispilot]

It looks like it. Making an animated EVA person might be a start for me. It would be like a robitic arm. Press a key and move left arm,.....

Not sure if you could make the actions match movement. So if you move forward the legs move forward.

 

[GLS]

I think EVAs are a little down the road at the moment... we still have to get into orbit correctly first.

 

[gattispilot]

OK. Not sure how I can help then?

 

[Urwumpe]

The main problem I see is more trivial actually.

The project is so far lost in a hamster wheel of implementing new features, that the foundation is completely forgotten: There has to be a coding standard and a quality assurance of the contributions. SSU needs standards and standard frameworks - has anybody lately looked how much of the source code has no comments at all? How could somebody develop a new feature, if there is no help at all where to start? On one end SSU wants to do feature-driven development, on the other hand the necessary homework to do that is not done.

Also I think that more coders won't fix it - SSU would need one or two developers working on the main branch of SSU, implementing no new feature at all. Just analysing what is implemented, how it is implemented, refactor it, make everything uniform in coding style and architecture. And this alone could take a year, before any new feature could get added safely.

Before somebody complains here: A lot of the most sloppy code in SSU has been written by me, I know it.

But before we could let a beginner like gattispilot write a single line of code for SSU, we should make sure that we don't do two dangerous errors:

• Burn him out faster than a Sprint first stage by overwhelming his abilities
• Having to throw his work away because it is ultimatively unusable for the future, simply because we did not say in advance, what we expect.

We are not doing us any favor there, if the project SSU isn't managed. And managed does not mean, having nice friendly titles for every uninvolved person and noble positions for interested users, like common in many VSAs... it means knowing what every component of the software does and why it behaves that way. Regardless who does which task in SSU, he should be able to do it or be able to find a manual on how to do it.

 

[GLS]

Yeah, we really should take some time and do a "cleanup". Right now the Atlantis.cpp file has over 8000 lines, and I would say 30-40% is old commented code, which doesn't help when navigating in there. Also, there's some code in there that could be in other files, so we could have the systems +/- organized and have mainly SSU-Orbiter interaction in the Atlantis.cpp file.

About the documentation: I have done a few excel files with tables and stuff that help explain some of the things I'm doing in the MPS/SSME world (lists of valves and commands and so), and believe it or not this afternoon I was doing a "compilation" of all the discrete bundles and lines and their function. I'm planning to upload all that towards the end of the mps branch (hopefully within weeks) (If any dev wants it before please say).
Anyway I still need to right more comments :facepalm:

 

[SiameseCat]

So I'm doing the "propellant revolution", and to begin I moved the ET tank to the Atlantis_Tank vessel, and have a "MPS manifold tank" that feeds the SSMEs, and that calls the tank to "use" it's propellant (which I decrease accordingly using SetPropellantMass()).
Then I run this, and the mass of the vehicle is not decreasing :facepalm: (and of course it fails to get into orbit), although in the ScenarioEditor I see the ET propellant mass decrease at the appropriate rate.
Orbiter bug, am I doing it wrong or can't be done this way?

---------- Post added at 01:36 PM ---------- Previous post was at 01:51 AM ----------

Did a little more digging and managed to "fix" the issue by calling the UpdateMass() function in Atlantis every time I do the "ET mass update". Not really intuitive the way the mass of attached vessels is managed in Orbiter but looks like it works now.

(I think this "episode" also applies to the Centaur, when we get that to do in-flight propellant dumps)

That sound right. Orbitersim ignores that mass of attached vessels; the UpdateMass function adds the mass of all the attached vessels to the shuttle mass.

The other problem you might have is with the CG updating code. Currently, the CG updating code estimates the ET CG based on the amount of propellant left in the ET tank resource. You'll probably have to change this a little.