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

[DaveS]

Before I file an official bug report, does any else besides me think that the orbiter handles really sluggishly in the roll channel during landing? It takes forever before the orbiter even begins to roll right now.

 

[GLS]

Before I file an official bug report, does any else besides me think that the orbiter handles really sluggishly in the roll channel during landing? It takes forever before the orbiter even begins to roll right now.

I noticed that too when updating the RHC. I found the pitch was too sensitive and the roll too lazy. This is related to the (simulated) rate of motion of the RHC when we press the key. I can make this rate faster, but that will make manual pitch control a handful. I think tweaking the AerojetDAP is probably better, but I'm not familiarized with the inner workings of the DAP. :shrug:

A couple of things that have to be done in the controllers are checking if the RMS THC works in the new way (6 = pull, 9 = push), and also changing the way the RHC works in orbit, to have sharper control of the RCS.

 

[Gingin]

Same for me here, very slow in roll compared to pitch channel during TAEM.

 

[GLS]

I'm working on adding holds to the (terminal) countdown as part of improving pre-launch checks, and as the holds when inserted (manually or automatically) are resumed or removed manually, I'm thinking about adding a very simple MFD to the LCC vessel to provide the user with basic interaction... good, bad or so so?

 

[Urwumpe]

I'm working on adding holds to the (terminal) countdown as part of improving pre-launch checks, and as the holds when inserted (manually or automatically) are resumed or removed manually, I'm thinking about adding a very simple MFD to the LCC vessel to provide the user with basic interaction... good, bad or so so?

Lets say it like that:

The holds are useful and should be used. We should be using L-Time and T-count I think as well.

I would think its better to have a Panel2D GUI for the LCC for having more freedom how the player can interact with it.

But its better to have a MFD now, than a Panel2D GUI in a year.

 

[DaveS]

I'm working on adding holds to the (terminal) countdown as part of improving pre-launch checks, and as the holds when inserted (manually or automatically) are resumed or removed manually, I'm thinking about adding a very simple MFD to the LCC vessel to provide the user with basic interaction... good, bad or so so?

Sounds good to me. Could things with respect to the MPS be changed so that everything happens on the scheduled time? I'm mainly thinking of the start of the LOX venting from the nozzles and the GVA.

Maybe also the LOX Drain back could be implemented. After all, you can't sit on the pad forever inside T-4:55 minutes as LOX drains back to the LOX facility at the pad at 18 lbs/sec. Either you'll run out of LOX to make the MECO targets (performance violation) or you'll lose the ENGINE READY status as the engines will be too cold to start (low end of the start box).

 

[GLS]

I'm just trying to come up with something that works from T-9 minutes down, and does basic checks (for now) and stops the clock at the correct place... I'm not aiming that high and already it's not easy.

 

[GLS]

Urwumpe, do you know what the names/IDs of the GPC variables mean? (V90W8380C, V99X8828X, V41K1393X, etc) I figure the ones ending with X to be equivalent to a bool, but a table or something with concrete info would be much better than guessing.

 

[Urwumpe]

Urwumpe, do you know what the names/IDs of the GPC variables mean? (V90W8380C, V99X8828X, V41K1393X, etc) I figure the ones ending with X to be equivalent to a bool, but a table or something with concrete info would be much better than guessing.

Those are not variable IDs but measurement IDs, which identify measurements in the master measurement table of the telemetry. By those measurement IDs, you can define how to decode the telemetry packet stream of the space shuttle in various NASA tools.

You are right, X designates bits of a 16 bit word. I remember I had a definition of the scheme somewhere on my ExtHDD, I can look for it when I am at home.

I remember I wanted to create a reference file one day based on the few known measurements for example for the RMS. The official list is sadly not around for us, it seems.

---------- Post added at 02:06 PM ---------- Previous post was at 01:37 PM ----------

Correction: The correct term of the table is "Master Measurement List". Mea Culpa.

I have found a very nice source for getting MML number, variable description, telemetry frame number and sample frequency for a huge set of STS variables:

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

(Appendix A, pages 26 to 38)

Sadly a bit poor to read... but then it is a very very veery nice listing for my current development tasks.

---------- Post added at 02:50 PM ---------- Previous post was at 02:06 PM ----------

This here is a better source for measurement IDs:

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

At least, its better to read, higher quality.

 

[GLS]

As I'm improving the countdown, this is a good time to correct the sources of some commands related to liftoff (SSWS, SSME H2 burn igniters, HDPs, etc) and I found a small "architectural" issue with the MLP/vehicle interface. Currently in Atlantis there are functions to return vessel pointers to whatever is attached (ET, SRB and MLP), if it's still attached. So currently, when the attachment breaks, we consider the (data) connection to be gone. AFAIK that's OK for the SRBs and ET, but not for the MLP. The attachment simulates, and well, the HDPs... but no data goes thru them, it goes thru the T0 umbilicals. And here is the issue: at launch the HDPs are fired first and only after that are the T0 umbilicals are released... but with the current setup we can't do that as our connection to the MLP is gone after the HDPs fire. :facepalm:
Now, this is relatively easy to fix, but it requires a (tiny) change to those "pretty" Atlantis::GetXYZInterface() functions (only the MLP one)... and as I don't want to get hit in the head, again :shifty:, for violating some coding directive, I'm putting this here first. So, would it be OK to have a MLP pointer variable in Atlantis, and then have GetMLPInterface() check if is valid, and if not run the existing attachment-checking code? It would allow the MLP to be accessible after launch, but I'm not planning on calling back to ask how it looked from the ground. :shrug: :lol:

 

[Urwumpe]

As I'm improving the countdown, this is a good time to correct the sources of some commands related to liftoff (SSWS, SSME H2 burn igniters, HDPs, etc) and I found a small "architectural" issue with the MLP/vehicle interface. Currently in Atlantis there are functions to return vessel pointers to whatever is attached (ET, SRB and MLP), if it's still attached. So currently, when the attachment breaks, we consider the (data) connection to be gone. AFAIK that's OK for the SRBs and ET, but not for the MLP. The attachment simulates, and well, the HDPs... but no data goes thru them, it goes thru the T0 umbilicals. And here is the issue: at launch the HDPs are fired first and only after that are the T0 umbilicals are released... but with the current setup we can't do that as our connection to the MLP is gone after the HDPs fire. :facepalm:
Now, this is relatively easy to fix, but it requires a (tiny) change to those "pretty" Atlantis::GetXYZInterface() functions (only the MLP one)... and as I don't want to get hit in the head, again :shifty:, for violating some coding directive, I'm putting this here first. So, would it be OK to have a MLP pointer variable in Atlantis, and then have GetMLPInterface() check if is valid, and if not run the existing attachment-checking code? It would allow the MLP to be accessible after launch, but I'm not planning on calling back to ask how it looked from the ground. :shrug: :lol:

Well, we have very little coding directives right now. :lol:

Well, lets analyze:

1. No need for a generic interface, since the MLP in this case is very space shuttle specific.
2. We need a connection orientation
3. The T0-umbilical is largely independent of the HDPs
4. Should we change this interface ever, MLP and orbiter will need to be recompiled anyway.
5. Even for fill&drain, the orbiter would need to do calculations.

Still, I would recommend also storing the name of the MLP vessel in the orbiter, so we can restore the pointer when loading/saving a scenario. Also, I am not sure if using a OBJHANDLE between the callbacks would be smarter, since maybe pointers to a VESSEL might change one day. It could be smarter to get a pointer to the MLP on the first call in a pre or post step and release it again after the callback has processed, assuming that it at least stays constant during the callback.



And much better: A T0Reference class that bundles everything needed to get a T0 interface class during runtime or store the state that no T0 umbilical is available right now. And ignore outside it, that a MLP did ever exist - we only want the T0 interface, so no need to get the full MLP there. Just limit everything to what we really need to know.



And much much better: A IT0Reference interface, that has two implementations: An OrbiterRuntimeT0Reference class and a DummyT0Reference class


The DummyT0Reference class could then be used for testing functions of the STS orbiter without need to run Orbiter.

 

[GLS]

Well, we have very little coding directives right now. :lol:

Well, lets analyze:

1. No need for a generic interface, since the MLP in this case is very space shuttle specific.
2. We need a connection orientation
3. The T0-umbilical is largely independent of the HDPs
4. Should we change this interface ever, MLP and orbiter will need to be recompiled anyway.
5. Even for fill&drain, the orbiter would need to do calculations.

Still, I would recommend also storing the name of the MLP vessel in the orbiter, so we can restore the pointer when loading/saving a scenario. Also, I am not sure if using a OBJHANDLE between the callbacks would be smarter, since maybe pointers to a VESSEL might change one day. It could be smarter to get a pointer to the MLP on the first call in a pre or post step and release it again after the callback has processed, assuming that it at least stays constant during the callback.



And much better: A T0Reference class that bundles everything needed to get a T0 interface class during runtime or store the state that no T0 umbilical is available right now. And ignore outside it, that a MLP did ever exist - we only want the T0 interface, so no need to get the full MLP there. Just limit everything to what we really need to know.



And much much better: A IT0Reference interface, that has two implementations: An OrbiterRuntimeT0Reference class and a DummyT0Reference class


The DummyT0Reference class could then be used for testing functions of the STS orbiter without need to run Orbiter.

So, first up is add a new scenario file parameter to the main SSU vessel with the MLP vessel name? Specifying the vessel names helps in case we want to have more than one Pad, MLP or LCC in the scenario.
The OrbiterRuntimeT0Reference class would then get the MLP name, get the MLP vessel pointer, and then when we want something from the MLP we call the appropriate function in OrbiterRuntimeT0Reference (and the MLP would call us via OrbiterRuntimeT0Reference as well).
Also, should the inter-vessel communications be via the vessels in between? LCC <> (Pad <> MLP) <> Vehicle? (Pad and MLP are the same for SLC-6) It makes sense to use the new T0 umbilical class to talk to the LCC. :shrug: (in real life it can talk via RF, but Martin hasn't implemented EM waves yet )
To simulate T0 umbilical data disconnection, the OrbiterRuntimeT0Reference class would "listen" to what we ask it to do, and when we say "Fire T0 Umbilical PICs" it does that and then nothing else.

Did I get it right? (sounds good to me)

 

[Urwumpe]

So, first up is add a new scenario file parameter to the main SSU vessel with the MLP vessel name?

Yes - as long as it is connected to a MLP. Otherwise we don't need it.

The OrbiterRuntimeT0Reference class would then get the MLP name, get the MLP vessel pointer, and then when we want something from the MLP we call the appropriate function in OrbiterRuntimeT0Reference (and the MLP would call us via OrbiterRuntimeT0Reference as well).

Yes, but don't return the vessel pointer there. Better make a interface class as described and either implement the interface in the MLP vessel itself (class MLP: public VESSEL3, public IT0Umbilicals) or make the MLP return the interface via a function call (GetT0Umbilicals) and leave the implementation of the IT0Umbilicals the exclusive job of the MLP, with the SSU orbiter having no idea about the implementation details at all.

I think the first one is slightly better for the SLC-6 case, because we could then just drop the name of SLC-6 Pad in place of the name of the MLP, without any special code required in the SSU orbiter.

Also, should the inter-vessel communications be via the vessels in between? LCC <> (Pad <> MLP) <> Vehicle? (Pad and MLP are the same for SLC-6)

Yes. Remember: Failures. Also, if we are on the MLP, but not on the Pad (crawler!), we don't want to have communication with the LCC.

It makes sense to use the new T0 umbilical class to talk to the LCC. :shrug:

Yes, it should hide the whole interaction that happens between from orbiter and LCC in lower layers in the vertical structure of SSU. For the orbiter, it should be like it is talking to the LCC directly. (Remember: OSI layer model there as example)

(in real life it can talk via RF, but Martin hasn't implemented EM waves yet )

Can be fixed... theoretically open for others by using clbkGeneric for this and just standardize the communication protocol.

To simulate T0 umbilical data disconnection, the OrbiterRuntimeT0Reference class would "listen" to what we ask it to do, and when we say "Fire T0 Umbilical PICs" it does that and then nothing else.

Yes. You could of course implement the basic T0Reference class as implementing the IT0Umbilicals interface and use it as proxy. When a Pad or MLP is connected, the T0Reference will behave just like a IT0Umbilicals implementation and forward all calls to the connected vessel. When no such vessel is connected anymore, it simply does nothing at all.

 

[GLS]

We already have an interface for the MLP (ISSUMLP), which contains some basic MLP activities, and both the MLP and SLC-6 vessels implement it. That can be used, or should we have separate interfaces for each of the vessel interfaces? SSU<>MLP, MLP<>Pad and Pad<>LCC, so that would be 5 interfaces total, plus our T0Reference class in Atlantis.
Also, should all the vessels have the name of what is attached to them in the scenario?

 

[Urwumpe]

We already have an interface for the MLP (ISSUMLP), which contains some basic MLP activities, and both the MLP and SLC-6 vessels implement it. That can be used, or should we have separate interfaces for each of the vessel interfaces? SSU<>MLP, MLP<>Pad and Pad<>LCC, so that would be 5 interfaces total, plus our T0Reference class in Atlantis.

Yes, thats no problem. Its better to have many clear documented interfaces than many undocumented ones. After all, even if those classes would not exist, the interaction between the vessels would stay.

Also, I still think a special T0 Interface is better than just extending the ISSUMLP - it does a lot of stuff that is not related to the T0 and which could lead to strangeness if used differently than intended.

Also, should all the vessels have the name of what is attached to them in the scenario?

Yes - that is the most robust and most portable way. Otherwise we would for example need a fixed naming scheme for automatic detection. And other problems. Lets keep it simpler.

 

[GLS]

Quick question: we currently have the ISSUMLP and ISSULaunchTower classes in libUltra... should the new ones also go in there, or should they be on their own (I vote for this option).

 

[Urwumpe]

Quick question: we currently have the ISSUMLP and ISSULaunchTower classes in libUltra... should the new ones also go in there, or should they be on their own (I vote for this option).

Hmmmmm....

In a different project, I would say, put it into the include folder of the module as public interface of it... So, into the include folder of the orbiter as definition of the "T0Umbilicals" interface, which could be included in the other projects for implementing their implementations of it...

Yes, I really think one day we should refactor the SSU folder structure a bit... but not now?

 

[GLS]

Hmmmmm....

In a different project, I would say, put it into the include folder of the module as public interface of it... So, into the include folder of the orbiter as definition of the "T0Umbilicals" interface, which could be included in the other projects for implementing their implementations of it...

Yes, I really think one day we should refactor the SSU folder structure a bit... but not now?

Maybe I'm tired, but I read that 3 times and can't figure out which option you want. :lol: The T0Reference class for the main SSU vessel will go into our main folder, and IMO so should the other ones.

BTW: I came up with this naming scheme, where the first name is the vessel implements the interface, and the second is the vessel "on the other side".
T0UmbilicalInterface
MLPPadInterface
PadMLPInterface
PadLCCInterface
LCCPadInterface

---------- Post added at 08:21 PM ---------- Previous post was at 07:59 PM ----------

Question about the SSWS: are there any valves in the MLP, or it's all controlled from the pad? Same for Firex? If so we could put all the water particle stream generation in the pad vessel.

 

[DaveS]

Question about the SSWS: are there any valves in the MLP, or it's all controlled from the pad? Same for Firex? If so we could put all the water particle stream generation in the pad vessel.

As far as I can tell, there's no valves whatsoever in the MLPs as far as SWSS and FireX is concerned. I think the valves are only on the water tower.

 

[Urwumpe]

Maybe I'm tired, but I read that 3 times and can't figure out which option you want. :lol: The T0Reference class for the main SSU vessel will go into our main folder, and IMO so should the other ones.

Seriously. I am not even sure myself. :lol:

I just want to declutter the main folder a bit, its too much in it already. libUltra on the otherhand already gets too much space-shuttle specific stuff in it, which makes it harder to use it for other projects.

Maybe a good rule would be like that:

A DLL that provides a public interface, should define it in a special include folder for that DLL. A DLL that implements that interface does not need to publish this.

So, we would just need to make sure that we can get that implementation. One way would be making the full vessel class definition of MLP or Pad public. I am not sure this is helpful since we are only interested in one or two functions there. Maybe a limited interface would be wiser there as well.