SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[GLS]

After reading GLS's post, this are my thoughts exactly. MECOTool worked great in the past, when the ascent was simpler in terms of events. But now that we have a more fleshed out MPS that includes the tail-offs and MPS dumps (this is what, a 10-15 fps dV addition?), MECOTool has gotten out of date. And I think that shows as it still includes an option for SSU v1.06!

But does the ascent guidance math really explain a 19.088 km discrepancy? That's the difference I came to when I finally reached the MECO apogee target I wanted. The target deltas are as follows: MECOVel: 4.042308, MECOFPA: 0.053378.

If you really think it comes from MECOTool, by all means check the math.

There are 2 "conversions" going on here:
- first we want to go to XYZ orbit, and we input that in MECOTool which converts this into MECO and OMS targets
- then our AscentDAP takes those targets and flys the ascent, and it should produce our requested XYZ orbit.

Take no offence but you keep saying that the first conversion is wrong, but never question the second.
We could make MECOTool absolutely perfect (that would include have it cook :lol, and still the AscentDAP pitch instability close to MECO would throw the best of targets out the window as the resulting FPA would be wrong. :shrug:

 

[Urwumpe]

We could make MECOTool absolutely perfect (that would include have it cook :lol, and still the AscentDAP pitch instability close to MECO would throw the best of targets out the window as the resulting FPA would be wrong. :shrug:

Well, lets start at the easy problem: The cooking, what is your favorite recipe? :lol:

 

[GLS]

Yes. 10-20 fps is about the magnitude of the factors we are currently ignoring. But MECOTool was already slightly inaccurate before, so no big surprise.

If I remember well, the issues I found with MECOTool were a different Earth radius than the one Orbiter uses, and the MU value could also be more precise.
Both issues were corrected on MECOTool (but not committed as it is so hated), but the "MECO (legacy)" tab in SSUWorkbench has those corrections, plus the MECO Pe altitude option (which was grayed out but I'm committing a change for that).

 

[Urwumpe]

Both issues were corrected on MECOTool (but not committed as it is so hated), but the "MECO (legacy)" tab in SSUWorkbench has those corrections, plus the MECO Pe altitude option (which was grayed out but I'm committing a change for that).

I still did not find much time learning C# yet. :facepalm:

---------- Post added at 15:41 ---------- Previous post was at 14:50 ----------

BTW, this here might be historically interesting, despite not solving any of our current issues... just look at the end of it for the large black bars for "LOSS OF CREW AND ORBITER"

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100034892.pdf

 

[GLS]

One thing I'd like to address is RCS max load: currently we have a ceiling of 2387lbs that comes from (tank) capability as reported in SCOM (1464 + 923). But then looking at mission data, the max loads are FRCS 2473lbs and combined ARCS 5384lbs (2692lbs per pod), with most flights having FRCS ~2450lbs and combined ARCS ~4970lbs (2485lbs per pod).
Shall I go ahead and correct our numbers for the max load, and put down the mass differences as prop in the manifolds, or are there any other ideas?

 

[DaveS]

One thing I'd like to address is RCS max load: currently we have a ceiling of 2387lbs that comes from (tank) capability as reported in SCOM (1464 + 923). But then looking at mission data, the max loads are FRCS 2473lbs and combined ARCS 5384lbs (2692lbs per pod), with most flights having FRCS ~2450lbs and combined ARCS ~4970lbs (2485lbs per pod).
Shall I go ahead and correct our numbers for the max load, and put down the mass differences as prop in the manifolds, or are there any other ideas?

I'd say go ahead and correct. Seems like a reasonable number (86 lbs) for what could be in the manifolds as residuals from S0024. On some missions I have heard the crew actually report the propellant loads when asked by the OTC as being slightly above 100%.

 

[Urwumpe]

One thing I'd like to address is RCS max load: currently we have a ceiling of 2387lbs that comes from (tank) capability as reported in SCOM (1464 + 923). But then looking at mission data, the max loads are FRCS 2473lbs and combined ARCS 5384lbs (2692lbs per pod), with most flights having FRCS ~2450lbs and combined ARCS ~4970lbs (2485lbs per pod).
Shall I go ahead and correct our numbers for the max load, and put down the mass differences as prop in the manifolds, or are there any other ideas?

I think some fuel extra in the lines makes sense, but I would then rather go the following path: If something depends on research and calculations on our side, we should make it configurable via cfg file. If something is a natural constant, not, for having better compiler optimization. Even if constants changed since 1970, we would then correct the researched data, than the value of a constant.

Also, I would keep tank volume and any volume in lines between valves and tanks separated. We can be more correct on the tank volume as on the propellant values. And do the propellant values include just propellant? Was it densified? Or does it include pressurant mass as well?

 

[GLS]

About the OMS burns ticket changes: I think a step backwards was taken there...
Reading the SCOM I looks like the OMS trim numbers are meaningless for the OMS TVC SOP, which is what controls the gimbals, and appear to only be used for the position of the ADI error needles (there's a thread somewhere in which Thorsten has the same interpretation).
Anyway, here's the relevant part:

OMS burn thrust vector control (TVC) is
calculated independently from the ADI error
needles.
• OMS TVC gimbals the OMS engines to
null vehicle rates and point sensed
thrust in the desired ΔVTOT direction.
• ADI error needles display vehicle
attitude error from the attitude that
would point the net thrust through the
c.g., as defined by the trim angles, and
in the desired ΔVTOT direction. If trim
angles are incorrect or flight control
does not recognize an engine failure, the
ADI error needles will not display
correct error information.

So the trim angles should not be used in the OMS TVC control, and it appears we are using them.

Then as r2738 changed the directions of the OMS engines, I decided to check those and according to diagram 9.13 of the Space Shuttle Systems Handbook the new values are wrong. Looking at the engine positions, at least the X coordinate is wrong, both in the code and in the mesh.

According to the diagram the engine direction should be (+/-0.113203, -0.27053, 0.956033) using YP rotation order, or (+/-0.108926, -0.27228, 0.956033) for PY... and I don't know which is the correct... :uhh:
Here's the diagram:

The different engine perspective in the 2 views might be a clue... but I'm not getting it... :facepalm:
BTW, we might have the same rotation order issue with the SSME directions.

 

[Urwumpe]

The trim angles are the "initial values" for the differential equation system, that the TVC guidance loops controls. By choosing good initial values, you prevent oscillations and overshooting = more accuracy, less residuals.

Isn't the OMS Burn guidance itself open loop = just burns for the calculated time in the calculated direction and does not correct thrust errors?

 

[DaveS]

About the OMS burns ticket changes: I think a step backwards was taken there...
Reading the SCOM I looks like the OMS trim numbers are meaningless for the OMS TVC SOP, which is what controls the gimbals, and appear to only be used for the position of the ADI error needles (there's a thread somewhere in which Thorsten has the same interpretation).
Anyway, here's the relevant part:

So the trim angles should not be used in the OMS TVC control, and it appears we are using them.

Then as r2738 changed the directions of the OMS engines, I decided to check those and according to diagram 9.13 of the Space Shuttle Systems Handbook the new values are wrong. Looking at the engine positions, at least the X coordinate is wrong, both in the code and in the mesh.

According to the diagram the engine direction should be (+/-0.113203, -0.27053, 0.956033) using YP rotation order, or (+/-0.108926, -0.27228, 0.956033) for PY... and I don't know which is the correct... :uhh:
Here's the diagram:

The different engine perspective in the 2 views might be a clue... but I'm not getting it... :facepalm:
BTW, we might have the same rotation order issue with the SSME directions.

The order confused me too but it seems to be YPR. It's consistent with the coordinates system where X is lateral, Y is vertical and Z is longitudinal. I based my directions on a diagram found in the SODB.

 

[GLS]

I think some fuel extra in the lines makes sense, but I would then rather go the following path: If something depends on research and calculations on our side, we should make it configurable via cfg file. If something is a natural constant, not, for having better compiler optimization. Even if constants changed since 1970, we would then correct the researched data, than the value of a constant.

Also, I would keep tank volume and any volume in lines between valves and tanks separated. We can be more correct on the tank volume as on the propellant values. And do the propellant values include just propellant? Was it densified? Or does it include pressurant mass as well?

The He mass probably isn't in those numbers, and even if it was it would be very small. IMO densification and compression should not be a factor here... any chemists around to expand on the properties of MMH and N2O4?
As for separating tanks from lines... we would need the volume of both those things, and as the RCS tanks have stuff inside, even that should be hard to find. In the end, the lines between the tank and the first isolation valves are always full so they could also be considered "tank volume"... Anyway we shouldn't need that unless we want to fire the RCS jets until we just have prop in the lines, and jet x has 5 pulses left and jet y has 2, etc...

My intent with this is just to decrease the mass error a little bit more and not change the current RCS (/OMS) stuff. IMO we should scale our prop resources to allow the maximum load seen (FRCS 2473lbs and each ARCS 2692lbs), and put the average load as a default "nominal load" in the SSUWorkbench (FRCS ~2450lbs and each ARCS ~2485lbs).

 

[DaveS]

Here's the OMS Workbook: https://sourceforge.net/projects/shuttleultra/files/References/OMS 21002.pdf/download

It should be of some help.

 

[GLS]

The order confused me too but it seems to be YPR. It's consistent with the coordinates system where X is lateral, Y is vertical and Z is longitudinal. I based my directions on a diagram found in the SODB.

Correction to my previous vectors, using the 15º49'28'' angle from that diagram instead of 15.8º:
YP +/-0.113203, -0.270938, 0.955917 and PY +/-0.108913, -0.272691, 0.955917.

With YP order the pitch angle is the same as the diagram (15.824444º) and yaw is 6.75372º. With PY order the yaw is the same (6.5º) and pitch is 15.9216º.
The alternative is to force (with trigonometry) both angles to be correct. :shrug:

---------- Post added at 09:00 PM ---------- Previous post was at 08:35 PM ----------

Here's the OMS Workbook: https://sourceforge.net/projects/shuttleultra/files/References/OMS 21002.pdf/download

It should be of some help.

I'll read that after dinner, thanks!
OMS engine directions, so angles between components match both angles in the diagram (+/-0.105128, -0.370911, 0.922699).

 

[DaveS]

I'll read that after dinner, thanks!
OMS engine directions, so angles between components match both angles in the diagram (+/-0.105128, -0.370911, 0.922699).

Those doesn't work. They lead to the OMS TVC being maxed out in pitch which cues in the RCS wraparound.

 

[Wolf]

Reading the SCOM I looks like the OMS trim numbers are meaningless for the OMS TVC SOP, which is what controls the gimbals, and appear to only be used for the position of the ADI error needles (there's a thread somewhere in which Thorsten has the same interpretation).

Maybe you are referring to this:

https://www.orbiter-forum.com/showthread.php?t=38432&page=11

 

[Urwumpe]

Can somebody help me about this paragraph:

The minimum altitude for an OMS engine burn is 70,000 feet. Below this altitude, the pressure difference between the inside and the outside of the OMS engine nozzle could cause it to collapse.

How could a rocket engine collapse by increasing pressure inside it? :blink:

 

[GLS]

That is probably "bad wording". The issue should be, like in the SSMEs, flow separation in the nozzle producing asymmetrical forces and probably breaking it.

Anyway, from that document I gather that the trim angles are used for the initial position of the OMS engine, so the initial "c.g. search" is easier.
This is do-able, by keeping the current position of OMS engines... which should be done by an non-existing OMS subsystem. To not save the engine position, we can just disable the trim by not using it.

---------- Post added at 10:54 PM ---------- Previous post was at 10:43 PM ----------

Those doesn't work. They lead to the OMS TVC being maxed out in pitch which cues in the RCS wraparound.

That will probably happen if you input someting in the trim items, which are currently added to the calculated gimbal positions... with the trims at 0 it should work.
We have to move some code out of OrbitDAP to a OMS TVC SOP, and correct the RCS wraparound which is currently triggered when an OMS engine hits its TVC limit instead of being triggered by attitude excursions. All of this requires work on the "end-of-life" GPCs...

 

[Urwumpe]

Anyway, from that document I gather that the trim angles are used for the initial position of the OMS engine, so the initial "c.g. search" is easier.

As I said above. Maybe with too exotic words.

This is do-able, by keeping the current position of OMS engines... which should be done by an non-existing OMS subsystem. To not save the engine position, we can just disable the trim by not using it.

What is the goal of this change? I think I missed this in the discussion somewhere.

---------- Post added 19th Dec 2017 at 00:05 ---------- Previous post was 18th Dec 2017 at 23:59 ----------

All of this requires work on the "end-of-life" GPCs...

Working on it. Just found out the hard way during prototyping that using a mutex per thread was a very very very stupid idea. Just because it looks better in simple scenarios does not mean it reacts well with different tasks.

Next solution would be a thread pool and a synchronization barrier.

 

[GLS]

As I said above. Maybe with too exotic words.

I missed that post.. :uhh:

What is the goal of this change? I think I missed this in the discussion somewhere.

Currently there are 2 ways of doing this: keeping the position of the engines, which would make it easier to do aminations and gimbal checks, etc, but means we need to have a subsystem to manage those positions, OR a faster/"probably not better"/cheaper way is to ignore the trim, keep the engines at 0º/0º except for the burns... OR (and I missed this on my "initial assessment" :facepalm we can use the trims to set the initial positions in the sw and leave the engines at 0º/0º except for the burns and the 15s before TIG when the initial gimbal is made.

Working on it. Just found out the hard way during prototyping that using a mutex per thread was a very very very stupid idea. Just because it looks better in simple scenarios does not mean it reacts well with different tasks.

Next solution would be a thread pool and a synchronization barrier.

Why a thread pool? Will you not run one GPC per thread? We know there are 5 of them...

 

[Urwumpe]

Because we have not 5 GPCs. We have 4 PASS GPCs running almost perfectly synchronous at times with up to 32 parallel tasks (FCOS limit) being executed, while other activities are done in the background by hardware. We have up to 25 I/O programs being executed by each IOP in parallel in the mean time (hardware limit, MSC + BCEs, but time division multiplex). And there is a BFS GPC somewhere in between doing its thing. (EDIT: And that is not the worst case. The worst case is during rendezvous, with 32 GNC tasks and 32 SM tasks. And then comes I/O.)

Would the number just be five, we would not have a problem. Would we just care for the 32 + 1 tasks being executed in parallel, we would still have a smaller problem.

Just serializing the PASS software would also not work out. We would replace finding a solution to making multiple threads run fine in the background of Orbiter by finding a way to define a multiprocess real-time system in a single thread and split it into frame-lengthed segments. I tried this a few times without getting into madness every time a new process is added into the system. Especially it would make it very hard to wait for I/O or special events in it, while it is a single liner in a thread.

We could just focus on making the displays run nice and pretend something happens - but this would mean everything that is not visible directly would not be happening or happening at the wrong time, just like the real-time behavior when interacting with them. And adding new displays like the payload specific ones would be much harder.

Sorry, but I hardly see any good chance to get past this. Even emulating the CPU would just solve a fraction of the problem and replace it by a new one. The idea to focus on the software partitions running the same software in sync sounds like the most economic approach in multiple ways. Out of multiple difficult approaches, its the least bad one.

I just have rarely more than 2 hours per week for working on any Orbiter project and my brain is still to badly damaged by my almost previous paid project. :facepalm:Almost previous - I still don't trust the calm.

---------- Post added at 01:10 ---------- Previous post was at 01:04 ----------

And can't we just add a OMS TVC subsystem for each engine and have a separate OMS engine handling the chemical work?