SSU Development Thread (2.0 to 3.0)

[Urwumpe]

A default RCS PRI RATE of 2.0 deg/s is way too high. Looking at the DAP tables for STS-134 (https://www.nasa.gov/centers/johnson/pdf/539927main_ORB_OPS_134_F_A_1.pdf), the PRI ROT RATE is usually 0.2 deg/s, or less, with the maximum value being 0.5 deg/s.

Those are on-orbit, not transition. I know that 2.0°/s is likely pretty high, even half of it would appear fast - but the pitch down for ET photography is at 2.0°/s according to the ASCENT CL, that is the value that I used for reference.

The problem is just: At 0.2°/s, a 180° maneuver would take just 900 seconds or 15 minutes. We need about 24 minutes for getting from MECO attitude to OMS-1 attitude.

And as another problem: Attitude hold does not work in OPS 104, the propellant dump makes the Shuttle tumble.

---------- Post added at 10:09 AM ---------- Previous post was at 09:48 AM ----------

Another theory, that I have not yet checked... are we in VERN mode in some scenarios? In the big one, it does not matter because VERN is not supported by Transition DAP (like many other DAP modes)

 

[GLS]

Those are on-orbit, not transition. I know that 2.0°/s is likely pretty high, even half of it would appear fast - but the pitch down for ET photography is at 2.0°/s according to the ASCENT CL, that is the value that I used for reference.

The problem is just: At 0.2°/s, a 180° maneuver would take just 900 seconds or 15 minutes. We need about 24 minutes for getting from MECO attitude to OMS-1 attitude.

And as another problem: Attitude hold does not work in OPS 104, the propellant dump makes the Shuttle tumble.

---------- Post added at 10:09 AM ---------- Previous post was at 09:48 AM ----------

Another theory, that I have not yet checked... are we in VERN mode in some scenarios? In the big one, it does not matter because VERN is not supported by Transition DAP (like many other DAP modes)

Can't the OMS-1 be heads-down? (or heads-up if it is like that at MECO) If I need to do an OMS-1, I hit "ITEM 5 + 180" and then it just needs to pitch 10º or so. In reality this would be part of the default targets.
I don't know the rates or attitude deadbands, but there is some yaw that builds in after MECO (caused by the LH2 dump), judging by the screens in the MCC in pre STS-107 flights.
For the ET photo pitch up, the crew would change modes in the OrbitDAP PBs (I don't remember what exactly, but there's a procedure somewhere) and the pitch caused by the LOX dump would be enough to turn around.

 

[Urwumpe]

The roll attitude is not the problem, but the pointing of the thrust axis. The whole attitude hold after MECO fails right now.

I still need to analyze the exact error sources there, why we are terribly off. I suspect that missing ILOADs is just one factor out of many there.


You can be sure in one factor: Right now, we test after a launch scenario, by following the ASCENT CL. But in our quick & really dirty DPS implementation, we use the Orbit DAP and not the correct Transition DAP, which behaves significant different.

(Our "Transition DAP" wrongly does the Z translation after ET separation, instead it would be responsible for turning manual and automatic rotation and translation commands into RCS firings. The Z-translation is commanded by the ET SEP process)

So, part of our quality assurance for this release should be making sure, that the orbit DAP push buttons and orbit DAP configuration data are set in a way, that the differences to the transition DAP are minimal.

EDIT: Also for the photography, the DAP pushbuttons for the pitch channel are moded from DISC to PULSE, YAW and ROLL are keeping zero rates in the selected navigation frame INRTL. Rotation should be between 2°/s and 3°/s. After Dump is complete, Pitch is moded back to DISC for continuing the maneuver. PULSE just provides a way to reduce the rotation rates by directly firing the active pitch down thrusters in a single pulse by moving the RHC forward.

 

[GLS]

The roll attitude is not the problem, but the pointing of the thrust axis. The whole attitude hold after MECO fails right now.

I still need to analyze the exact error sources there, why we are terribly off. I suspect that missing ILOADs is just one factor out of many there.


You can be sure in one factor: Right now, we test after a launch scenario, by following the ASCENT CL. But in our quick & really dirty DPS implementation, we use the Orbit DAP and not the correct Transition DAP, which behaves significant different.

(Our "Transition DAP" wrongly does the Z translation after ET separation, instead it would be responsible for turning manual and automatic rotation and translation commands into RCS firings. The Z-translation is commanded by the ET SEP process)

So, part of our quality assurance for this release should be making sure, that the orbit DAP push buttons and orbit DAP configuration data are set in a way, that the differences to the transition DAP are minimal.

EDIT: Also for the photography, the DAP pushbuttons for the pitch channel are moded from DISC to PULSE, YAW and ROLL are keeping zero rates in the selected navigation frame INRTL. Rotation should be between 2°/s and 3°/s. After Dump is complete, Pitch is moded back to DISC for continuing the maneuver. PULSE just provides a way to reduce the rotation rates by directly firing the active pitch down thrusters in a single pulse by moving the RHC forward.

I created the TransDAP and got it to do the Z-translation, and then I looked inside the OrbitDAP and got too scared to add anything else :facepalm:.
About the Z-translation: the command goes from the ET SEP Sequence to ASC RCS CMD SOP and TransDAP. If it is started by the ET SEP Sequence and then terminated by the TransDAP, I don't know, but the TransDAP is in it somehow.

 

[Urwumpe]

I created the TransDAP and got it to do the Z-translation, and then I looked inside the OrbitDAP and got too scared to add anything else :facepalm:.

I know. Part of our software development problem is, that we create too large classes with too large functions and too complex functions even for simple problems, because we overload them with functions that they never had in the real one.

Its just like Ascent DAP or RSLS also being responsible for handling display inputs or AerojetDAP painting the HUD (Actually, the controlling GPC only provide the navigation data to the HUD - the HUDs paint themselves). Its not just stupid from our own side to make our own life that hard. The software developers of the big one have also never done that, despite all pressure regarding the slow first generation AP-101s and the limited memory.

In the big one, the UI of the application software and the sequencing of the related tasks below the UI is done by special programs called "control segments", which are mostly made of HAL/S macro commands. All a lot more standardized and all a lot smaller than our code.

About the Z-translation: the command goes from the ET SEP Sequence to ASC RCS CMD SOP and TransDAP. If it is started by the ET SEP Sequence and then terminated by the TransDAP, I don't know, but the TransDAP is in it somehow.

I would need to look for the exact sequence again. I know that the TransDAP is responsible for executing the translation command, but I am not sure if the TransDAP also controls the 4 fps velocity change in Z. I would not be surprised if another process is active for that. During OPS1, there is for example also one process for IMU navigation and SuperG integration (velocity change!) active in the background.

About the differences between SuperG and various other tested functions, here is a 1979 NASA tech doc about it: http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19800018906.pdf

 

[GLS]

I know. Part of our software development problem is, that we create too large classes with too large functions and too complex functions even for simple problems, because we overload them with functions that they never had in the real one.

Its just like Ascent DAP or RSLS also being responsible for handling display inputs or AerojetDAP painting the HUD (Actually, the controlling GPC only provide the navigation data to the HUD - the HUDs paint themselves). Its not just stupid from our own side to make our own life that hard. The software developers of the big one have also never done that, despite all pressure regarding the slow first generation AP-101s and the limited memory.

In the big one, the UI of the application software and the sequencing of the related tasks below the UI is done by special programs called "control segments", which are mostly made of HAL/S macro commands. All a lot more standardized and all a lot smaller than our code.

On the display/HUD painting, the shared memory pool will help in making data available for that, making it easier to move the displays out of the SW classes.
I thing we have to do, it will probably hurt but should be done, is separating the FCS from guidance (both on ascent and entry), so we can go MAN and still keep the guidance outputting to the ADI needles.

I would need to look for the exact sequence again. I know that the TransDAP is responsible for executing the translation command, but I am not sure if the TransDAP also controls the 4 fps velocity change in Z. I would not be surprised if another process is active for that. During OPS1, there is for example also one process for IMU navigation and SuperG integration (velocity change!) active in the background.

In the diagram I have, the ET SEP Sequence just sends that command, it doesn't do anything related to stopping the Z-translation.

 

[Urwumpe]

I thing we have to do, it will probably hurt but should be done, is separating the FCS from guidance (both on ascent and entry), so we can go MAN and still keep the guidance outputting to the ADI needles.

Might be not too hard, if we follow some layering there. Remember, one process should in the ideal case just have one responsibility. In the real shuttle software, the number of processes was limited, so this coercion criteria was softened towards just minimizing the number of responsibilities.

In the diagram I have, the ET SEP Sequence just sends that command, it doesn't do anything related to stopping the Z-translation.

That should be correct. As far as I can tell about the HAL/S FC programming used in the shuttle, there are no commands that are send around inside the GPC software. You actually set/reset special 16 bit event variables.

In the case of the ET separation, this would mean: The ET SEP process and the "translation process" had been started as software at the same time, but the "translation process" goes into a WAIT state for the event flag "all connections to the ET separated" - FCOS now checks during every process switching event, if the variable that the translation process waits for has been set. When the ET SEP process has done its job, it sets this flag and the translation process can resume execution. The process management of FCOS does a lot of magic, its quite interesting.

Now the problem is just: How to tell that 4 fps in Z have been reached? Such a problem is exactly what the SuperG integration should solve, so I would expect that it is used there, just like it would be used for OMS maneuvers in OPS1 or OMS/RCS maneuver in OPS2.

 

[GLS]

My data comes from this 3 NTRS docs: 19800073367_1980073367, 19810072044_1981072044 and 19820066528_1982066528 (not sure if they are still available).

Changing subject: is there a way of having control over what vessel attaches at a certain attachment? It would be nice to have just the IUS attach to the ASE and the Centaur G to the CISS G, etc. I though the the "id" string was for that ("The identifier string can contain up to 8 characters. It can be used to define compatibility between attachment points.") but it doesn't seem to work.... does it need "active" checking?

 

[Urwumpe]

does it need "active" checking?

Yes, attachments are fully user-defined in their run-time behavior - you can have a IUS at ANY other attachment in the scenario file, if you want it so.

---------- Post added at 02:51 PM ---------- Previous post was at 02:44 PM ----------

My data comes from this 3 NTRS docs: 19800073367_1980073367, 19810072044_1981072044 and 19820066528_1982066528 (not sure if they are still available).

Short check: No.

 

[GLS]

Yes, attachments are fully user-defined in their run-time behavior - you can have a IUS at ANY other attachment in the scenario file, if you want it so.

Any preference of where those checks will be made (upper stage vessel vs SSU subsystem)?

 

[Urwumpe]

Any preference of where those checks will be made (upper stage vessel vs SSU subsystem)?

I think that attachments should be part of the Atlantis class. Maybe we should make a smoke test in clbkPostCreation to test if the attachments are all valid, after loading a scenario.

For runtime changes (like installing a IUS into SSU in the RSS), the check should be delegated in a sane way to the subsystem, since even attachments with valid ID might be illegal at a point.

 

[GLS]

I think that attachments should be part of the Atlantis class. Maybe we should make a smoke test in clbkPostCreation to test if the attachments are all valid, after loading a scenario.

For runtime changes (like installing a IUS into SSU in the RSS), the check should be delegated in a sane way to the subsystem, since even attachments with valid ID might be illegal at a point.

Then it probably should go in the trunk, and maybe wait until after the release. If I forget to do it, somebody remind me please.

 

[Urwumpe]

Then it probably should go in the trunk, and maybe wait until after the release. If I forget to do it, somebody remind me please.

Its no urgent problem, who creates an illegal scenario deserves to be punished. :lol:

But the mission editor should of course produce legal scenarios.

 

[GLS]

I know I'll be shot for asking this so late, but could this external airlock "spacer/EVA hatch" be added?

IMO there's a strong case for having it forward of the airlock (for STS-74 and 88, top images), as without it the RMS probably can't dock Unity/DM to the ODS. As for the "aft" version for EVA access, we could leave it for addon devs for now, but we should consider also having the capability to add it.

 

[DaveS]

The "spacer" is called the Tunnel Adapter Assembly (TAA) and was first used on STS-9. It is 2.1336 m (84") long and has an inside diameter of 1.6 m (63").

 

[Donamy]

I have one I did for my STS-88 mission. I could make it available for SSU.

 

[Urwumpe]

I have one I did for my STS-88 mission. I could make it available for SSU.

Is it to scale? If yes, than there could be done support for it analog to the Airlock/ODS.

For the 4.0 version... do you also have the insides of tunnel and airlock? maybe we could combine this with a Spacelab interior to extend the middeck a bit...

Would be a rather cheap feature compared to the other ones.

 

[GLS]

Is it to scale? If yes, than there could be done support for it analog to the Airlock/ODS.

For the 4.0 version... do you also have the insides of tunnel and airlock? maybe we could combine this with a Spacelab interior to extend the middeck a bit...

Would be a rather cheap feature compared to the other ones.

An mission file option for turning this on, and maybe another for choosing the placement would be enough for now.

 

[Urwumpe]

An mission file option for turning this on, and maybe another for choosing the placement would be enough for now.

For now is until August 18. I already try to gather tickets for the next iteration, which will come.

 

[Capt_hensley]

I'd be interested in seeing how all this turns out after the events of late. But I am pleased it's making forward progress. Please by all means keep up the great work. Don is a very generous man, and the adapter is a fine work.

The comments above remind me of a line...

"Don't touch that please, your primitive intellect wouldn't understand alloys and compositions and things with... molecular structures." ~Ash, Army of Darkness.

A line which has no specific meaning or application here, just a random memory.