Payload Interface

[Urwumpe]

According to the EPS chapter of the SCOM, all orbiters can carry up to 5 nominal cryo tank sets, while OV-102 and OV-105 supports 4 additional tanks on the EDO pallet.

OK, so EDO is tank 6-9 and OV-105 can also support tank 10-13.

Though I can't find information, which tank 1-5 the second EDO pallet would use as connection. The first EDO connects to the manifolds on the same lines as tank set 3. My first guess would be tank 2, as tank 1 is the lowest numbered tank and tank 4 and tank 5 already share a connection (and panel).

 

[DaveS]

OK, so EDO is tank 6-9 and OV-105 can also support tank 10-13.

Though I can't find information, which tank 1-5 the second EDO pallet would use as connection. The first EDO connects to the manifolds on the same lines as tank set 3. My first guess would be tank 2, as tank 1 is the lowest numbered tank and tank 4 and tank 5 already share a connection (and panel).

Well, the only image I have found is an old SSF drawing showing Endeavour docked to SSF with the dual pallet in the payload bay.

 

[GLS]

OK, so EDO is tank 6-9 and OV-105 can also support tank 10-13.

Though I can't find information, which tank 1-5 the second EDO pallet would use as connection. The first EDO connects to the manifolds on the same lines as tank set 3. My first guess would be tank 2, as tank 1 is the lowest numbered tank and tank 4 and tank 5 already share a connection (and panel).

IMHO, the #2 EDO tanks are also connected to tank 3... or that or tanks 4 and 5. I doubt they connect to either tank 1 or 2....

 

[DaveS]

IMHO, the #2 EDO tanks are also connected to tank 3... or that or tanks 4 and 5. I doubt they connect to either tank 1 or 2....

Well, this is kinda academic since two EDO sets were never flown since the only LDO orbiter was Endeavour and she has had her EDO and LDO capabilities removed for the ISS missions. She did fly one EDO mission though, STS-68.

The only EDO orbiter after that was Columbia and she never had the LDO connections, just the EDO connections.

 

[DaveS]

As they appear to be looking correctly relative to each other otherwise, I will investigate where this change in position comes from. Maybe our offset variable is broken at a point.

Any progress in this investigation?

 

[Orbinaut Pete]

Hi all SSU team.

I'm going to PM you all soon with an update on ISSU, but I have had a few ideas for SSU, and I just wanted to post them here to see if they are possible, and whether you like them or not.


1.
(See picture 1) In this picture, you see the payload retention latches the shuttle uses on all flights. Note that on top of the payload retention latches, there is a "ring"

(See picture 2) In this picture, you see the shuttle payload bay is divided up into 13 bays, with 1 latch being able to occupy 1 bay. You can see the bays - they are separated by the lines that curve round the payload bay. You see the payload retention latches are the same width as 1 bay. You also see that there are 3 black "dots" on each bay. These are what the payload retention latches screw into.

(See picture 3) In this picture, you see the payload retention bars on the payloads themselves. These lock into the ring on top of the latches, and that is what holds the payload in the bay. There is one of these bars underneath the payload also.

(See picture 4) In this pic, you see there are different types of latches. This sort can be opened, so as payloads can be removed from the bay in flight . Others are fixed, and do not open (like in picture 1).

I'm sure you know all that, but for those that didn't, there it is.



Now, here's the part that relates to SSU:

Donamy has already designed these payload retention latches (called 124 bridgerail, in his STS-124 payloads pack). At the moment, they are separate vessels, but I think it would be cool if they could become part of SSU.

Here's an idea I had of how it could work.

In the scenario, you could add something like this:

PLDRTNLTCH1: 7S

PLDRTNLTCH = Payload Retention Latch
1 = which type, could be many (ones the are fixed or that open)
7 = which bay number (1-13)
S = Starboard or Port side of payload bay.

If you added locations correctly (so the centre screw-hole of each bay, and the the centre screw-hole of each latch line up), then when you type "10" the latch should line up with bay 10, etc. You could have as many latches as you needed in a scenario.

If you put 13 attachment points in the bay (attachment points being in the middle-centre of each bay, where the underneath payload retention bar on the payloads attaches to) then, providing you designed all the payloads to fit SSU correctly (like ISSU), with the attachment point on the underneath retention bar itself, then you should just be able to attach the payloads to the shuttle using attachment points 1-13, and as long as the retention bars are designed to line up, they should line up perfectly with the latches.:speakcool:

Maybe you could even add something to the payload bay control panel to be able to release the latches & unlock the payload??

So just as an example, the scenario code for STS-126 could be:
(1= standard latch, 2= openable latch)

PLDRTNLTCH1: 13P
PLDRTNLTCH1: 13S
PLDRTNLTCH2: 12P
PLDRTNLTCH2: 12S
PLDRTNLTCH2: 8S
PLDRTNLTCH2: 8P

Then, the attachment point for the MPLM would be 0:10,Shuttle

Just an idea


This would help decrease the amount of vessels in a scenario, which is what I'm looking to do in ISSU. Also, these could then be used by any payload.


2.
It would be really cool if you guys could do an interior for the ODS, + animations to open top hatch. Now ISSU is back online, one of the first tasks I think, should be a PMA + interior, so that you guys can start working on the ODS docking ring stuff you need to do.



I really want SSU + ISSU now to be like "brother" projects.

As I say, I will PM you all when I have got some more setting-up work done to let you know what's going on.

Cheers,

-Pete

 

[Urwumpe]

1. Payload latch types are defined already inside the payload lines. No need for adding new stuff. For really handling stuff, we will also need similar data in the payload configuration file, but this is currently not too important for us.

2. Meshes for the latches will come later, as well as linking them accurately to the ship circuits.

3. ODS interior can come later.

4. You can become our sister project, when you can keep up with us. The 1.25 release is currently our focus, I suspect after 1.25 we will work stronger on the ground infrastructure, as we have many developments there, waiting to get improved.

 

[DaveS]

Donamy and I was discussing this subject today. Any updates on this? If needed I could mesh the keel latches(they're very noticeable once the payload has been removed from the bay).

And speaking of that, how do we use the PAYLOADTYPE attachment IDs? Like these:
"XS1P", "XS3P", "XS5P",
"XS1A", "XS3A", "XS5A"

 

[DaveS]

Any answer to the question above?

 

[Urwumpe]

Any answer to the question above?

I think this has been the idea we initially planned, but we would be using "XS" internally in SSU all the time. Also, because we need extra information from the payload configuration file anyway, we could also put this information there as well, just say what you think is the simplest solution.

 

[DaveS]

What kind of extra information to we need from the payload config file?

If it is complicated information, I would say we put everything in the payload config file, with the SSU module only loads the appropriate latch meshes(trunnion and keel).

 

[Urwumpe]

What kind of extra information to we need from the payload config file?

If it is complicated information, I would say we put everything in the payload config file, with the SSU module only loads the appropriate latch meshes(trunnion and keel).

The positions of the passive half of the trunnions for example, so we can calculate and indicate "ready to latch".

 

[DaveS]

OK. Since it isn't that much, I really feel that putting everything in the config file is the way to go.

 

[Urwumpe]

OK. Since it isn't that much, I really feel that putting everything in the config file is the way to go.

We would also only need to read the data once, we can store it in a tiny cache afterwards.

 

[DaveS]

I think it would be good if this were given some attention. The earlier we can implement it, the better. That way we could also get the retention latches up and running and debugged.

 

[GLS]

BTW, what do you think about making the EDO-pallet a part of the SSU, like the ODS? Would make the implementation of the EPS simpler.

Makes perfect sense to me. Same goes for the OMS kit. For now it would only show the meshes and add the extra mass, but it's a start.

Another thing I've been thinking about are the bridge fittings (which we call bridgerails)... shouldn't we have the capability to add those (in this case keel bridge fittings) to the bottom of the PLB?

 

[Urwumpe]

Another thing I've been thinking about are the bridge fittings (which we call bridgerails)... shouldn't we have the capability to add those (in this case keel bridge fittings) to the bottom of the PLB?

Yes, if they mostly look the same, it should work the same way.

Maybe we need to break compatibility one day there in the mission files for describing the payload interfaces better. But not now.

 

[GLS]

Maybe we need to break compatibility one day there in the mission files for describing the payload interfaces better. But not now.

Not necessarily: we can add the new parameter for the keel bridges ("KeelBridges=xyz"), and add a new one with the correct name ("LongeronBridges=xyz"), while keeping the existing "Bridgerails=xyz" parameter for compatibility. The main code and the SSUWorkbench would read both versions, but SSUW would only save with the new name.
But yes, it does nothing for the attachments except add eye candy...

---------- Post added at 03:41 PM ---------- Previous post was at 01:05 PM ----------

(to avoid going off-topic here, the EDO talk continues over here)
I'll do the code work for the new bridge fittings after I finish the EDO stuff.

 

[GLS]

(I was going to create a new thread, but it seems one already exists so...)

As the possible attach positions on the PLB are defined, we could maybe take a small step forward in this area by allowing the user to specify what positions will be used and how, i.e., static attachment, releasable, guide plates. Those are standard parts (or they should be for the most part) so we can have one simple mesh of each and load instances of them as needed and place them in the desired attach location. All the user has to do is make the standard pin and position it correctly.
The attach positions would be defined via Mission File with array parameters, similar to the Bridgerails:

PortStatic=270,296,311
StarboardStatic=270,296,311
PortLatch=210
StarboardLatch=210
PortGuide=210
StarboardGuide=210

We would of course publish the position id and Xo position in the manual.
In my mind, for now, this would only control the visual side of the attachments, the physical side remains as is.

I'm just putting this idea "on paper" for consideration/discussion, implementation would only happen after SSU 5.0 is out the door.