Payload Interface

[DaveS]

For thw payload system: How are we going to handle RMS deployed payloads? Obviously we need a way to only semi-attach the payload to the RMS End Effector while it is still attached to the orbiter by the payload retention latches.

 

[Urwumpe]

I had sketched out such a system (as state machine) way back in this thread, but as long as we are concentrating on the first 50 minutes of flight, I did not think much morer about it. Basically it means that we have different states of HOW it is attached to the orbiter, if at all.

 

[DaveS]

Payload system

This thread is for discussions and updates of the new custom payload handling system for Space Shuttle Ultra.

I'll kick oit off by asking if there's any quick and dirty examples of the XML files for this purpose.

This way we can get people start working on adapting their payloads for SSU while it's being implemented.

 

[Urwumpe]

I'll kick oit off by asking if there's any quick and dirty examples of the XML files for this purpose.

This way we can get people start working on adapting their payloads for SSU while it's being implemented.

Not yet, we don't even have a XML parser for the project (but that would be a minor problem to get one).

I would say a good syntax would be something like:

<payloadconfig>
<payload type="1" z=0.0><further options/>...</payload>
<payload type="SideL1" z=0.0><further options/>...</payload>
<payload type="SideR1" z=0.0><further options/>...</payload>
</payloadconfig>

somewhere inside the mission file.

 

[DaveS]

Not yet, we don't even have a XML parser for the project (but that would be a minor problem to get one).

I would say a good syntax would be something like:

<payloadconfig>
<payload type="1" z=0.0><further options/>...</payload>
<payload type="SideL1" z=0.0><further options/>...</payload>
<payload type="SideR1" z=0.0><further options/>...</payload>
</payloadconfig>

somewhere inside the mission file.

But would it require anything from the payload authors, terms of special cfg data additions?

 

[Urwumpe]

But would it require anything from the payload authors, terms of special cfg data additions?

Well, I think about checking that a payload is compatible to the current latch configuration, when (re-)loading it. I wanted to do this by expecting the payload attachments to have a special ID. But I have not yet defined any system for them.


Something which contains the number of latches used and the configuration would be enough.

 

[DaveS]

Well, I think about checking that a payload is compatible to the current latch configuration, when (re-)loading it. I wanted to do this by expecting the payload attachments to have a special ID. But I have not yet defined any system for them.


Something which contains the number of latches used and the configuration would be enough.

Something like this maybe:

;===Configuration file for MPLM Leonardo===
Meshname = LeonardoMPLM
Size = 8
Mass = 11000
EnableFocus = TRUE
EnableXPDR = TRUE
 
; === Docking ports ===
BEGIN_DOCKLIST
0.0  0.0  3.137    0 0 1   0 1 0
END_DOCKLIST
 
; === Attachment specs ===
BEGIN_ATTACHMENT
P -0.05  -0.3  3.5    0 -1 0  0 0 1 XS
P  1.624  1.624 0.930   0.7071 0.7071 0 -0.7071 0.7071 0  GS
P -1.624  1.624 0.930  -0.7071 0.7071 0  0.7071 0.7071 0  GS
END_ATTACHMENT
 
; === Shuttle Ultra payload data ===
NumTrunnionLatches = 4
NumKeelLatches = 1
Deployable = TRUE

 

[Urwumpe]

I think that even does too much. What about replacing the "XS" in the attachment line with a "XS5" or "XS4+1"? This information can be grabbed directly from the SDK without us having to find out which configuration file we need to use.

 

[DaveS]

I think that even does too much. What about replacing the "XS" in the attachment line with a "XS5" or "XS4+1"? This information can be grabbed directly from the SDK without us having to find out which configuration file we need to use.

That sounds better and easier.

 

[Urwumpe]

That sounds better and easier.

Well, then. Which interfaces has the shuttle and which codes do we give them?

 

[DaveS]

Well, then. Which interfaces has the shuttle and which codes do we give them?

Well, payloads are only attached to the orbiter by the keel and trunnion pins. For a beginning, this is a good start. Orbiter attaches attachment points by checking where the center of each attachment point is, so how about XSKEEL and XSTRUNN?

 

[Urwumpe]

Well, payloads are only attached to the orbiter by the keel and trunnion pins. For a beginning, this is a good start. Orbiter attaches attachment points by checking where the center of each attachment point is, so how about XSKEEL and XSTRUNN?

Well, I think that could become unhandy, as we have only one letter left after "XSTRUNN". Also, I think we don't need to use special codes for the side mounted payloads - we can only attach them in-flight by using EVAs AFAIK.

 

[DaveS]

Any updates on the implementation of the payload system?

 

[Urwumpe]

Any updates on the implementation of the payload system?

Nothing new yet. Spent the morning hours for making a font bitmap for the MDU.

 

[DaveS]

Nothing new yet. Spent the morning hours for making a font bitmap for the MDU.

Nice. When it comes to the payload system, how about implementing the test versions into a "Payload Canister"? That way we could iron the bugs and polish it before putting it into SSU. People would also understand that it's a test version which may or may not represent the final version.

 

[Urwumpe]

Nice. When it comes to the payload system, how about implementing the test versions into a "Payload Canister"? That way we could iron the bugs and polish it before putting it into SSU. People would also understand that it's a test version which may or may not represent the final version.

Well, we could make the payload interface a logical subsystem and use the code base for the payload interface in such canister exactly like it would be used inside the Shuttle.

What about making the mesh for the horizontal payload test station (don't know the proper name), which also has the aft work station panels connected for testing?

 

[DaveS]

Well, we could make the payload interface a logical subsystem and use the code base for the payload interface in such canister exactly like it would be used inside the Shuttle.

What about making the mesh for the horizontal payload test station (don't know the proper name), which also has the aft work station panels connected for testing?

That one is located in the O&C Bldg. at KSC. Full name is Cargo Integration Test Equipment(CITE).

Here's some images of the CITE:
http://www.capcomespace.net/dossiers/espace_US/shuttle/ksc/ZI OCB CITE 01.jpg

http://www.capcomespace.net/dossiers/espace_US/shuttle/ksc/ZI OCB CITE 02.jpg

I guess it could be made.

 

[Urwumpe]

That one is located in the O&C Bldg. at KSC. Full name is Cargo Integration Test Equipment(CITE).
I guess it could be made.

Yeah, thats what I mean. Of course, it is useless to have a simulator inside a simulator.

 

[DaveS]

When looking for some information on the payload bay systems, I came across this very interesting United Space Alliance page: http://www.unitedspacealliance.com/icd/

Anyone want to have the ICDs for the Columbus module? Then check out the Archived section!

 

[Urwumpe]

When looking for some information on the payload bay systems, I came across this very interesting United Space Alliance page: http://www.unitedspacealliance.com/icd/

Anyone want to have the ICDs for the Columbus module? Then check out the Archived section!

Sweet!

I wanted to implement a first version of the payload system today, so this thing manages to get into the next release.