Space Shuttle Ultra development thread

[DaveS]

Are we close to a working model, so I can resume work on the panels ?

Well, things that need still fixing except for the forward panels is panel R2 talkbacks and panel R13L talkbacks.

 

[DaveS]

How about implementing OrbiterSound support into SSU? I have recently found a great clip of a static Full Scale Motor(FSM) testing firing which we could use as a engine sound during first stage ascent.

 

[Urwumpe]

Why not, we will need it anyway.

 

[DaveS]

Did we ever reach a decision on whether to use Kulch's Payload SDK?

 

[Urwumpe]

Not sure on the other developers, but my personal feeling after researching it currently is, that we don't need its special features and could do the payload handling with attachment points better, if we do it ourself.

Also, we could this way implement cable connections to payload panels easier.

 

[kulch]

Not sure on the other developers, but my personal feeling after researching it currently is, that we don't need its special features and could do the payload handling with attachment points better, if we do it ourself.

What is bad with my PM? May be it will be good to let me know?
I hope for any constructive criticism

 

[Urwumpe]

What is bad with my PM? May be it will be good to let me know?
I hope for any constructive criticism

Well, nothing bad with PM, just with our design goals.

We want to control the payloads over the various switches in the aft station. For some payloads, the realistic way would also consist of a custom panel with switches (Well, not too custom, the layout is given in the Shuttle Payload Interface Definition).

So, we would have 3 payloads maximal, which can get deployed directly by selecting the payload with a rotary switch on the aft station. Payloads in Gas containers or IUS/PAM/Centaur cradles would get controlled by a different system.

The problem with PM I see is, that it adds an additional layer of abstraction between the payloads and the Shuttle, which we actually don't need. Also, it's features like applying thrust from attached payloads is nice, but also not needed - active thrusters and the Shuttle Payload bay is per definition not compatible.

You can say, the PM is actually already too good for us. The good thing would be the scenario editor interface and large amount of features - the bad thing the virtual distance between payload and Shuttle.

 

[tblaxland]

Excuse me if I am talking out of school here because I haven't been involved in your development thus far, but I couldn't help but throw my 2 cents in.

As I understand it, PM would not add an extra layer of abstraction between SSU and your payloads because PM SDK provides you with a vessel class (VesselWithPM) that inherits the VESSEL2 class. So all your normal VESSEL2 functionality would remain intact and directly accessible but you also have the added PM functionality.

For me, this would be important for a creating once off "what if" payloads so that I would not have to create an interface to the Shuttle Payload Interface panels. This would not prohibit the more realistic payload control that you envisage, IMO.

 

[kulch]

Shuttle Payload Interface Definition

Can you get me the link? Where are can I read about?

the bad thing the virtual distance between payload and Shuttle

Why? The VesselWithPM interface is transparent for VESSEL2 calls. If you need to insert your own interface between VesselWithPM and Shuttle just use the second template definition in PayloadManager.h
For example (from my Energia):

class EnergyC :
public VesselWithPM<EnergyC, OverShip>
{
public:
...


Here EnergyC - Energia core stage interface and OverShip - subclass for interstage communication (between core and boosters for example).
was:
VESSEL2 - OverShip - EnergyC
now:
VESSEL2 - VesselWithPM - OverShip - EnergyC

 

[Donamy]

If it's something that will work now, with out alot of time developing a new one, might be the way to go. IMO

 

[kulch]

To be understood correctly. I do not wish to impose my solution. I just need some feedback about Payload Manager SDK.

 

[Urwumpe]

Can you get me the link? Where are can I read about?

The information for the real thing used to be here: http://shuttlepayloads.jsc.nasa.gov/

But the site is down, as I can see... :dry:


On the SSU development, I can make a small pdf with what I think could be a good way to do the communication with the payload. It is not final or the other developers agree that it is good...

In short form, my concept requirements:

First stage:
What should be an important aspect in the payload interface should be the capability to rotate an attachment point with its payload. Shuttle specific payload support structures (cradles) should be made part of the Shuttle itself.

Hardware which can get deployed, should have a line in the scenario file, how it is attached to the Shuttle (Up to 5 latches, all latches most be released for detaching the payload).

If rotating the attachment points is possible, this stage could be done with PM wrapped behind the VC, otherwise, we get in trouble.

Second stage: Connection to the VC.

For special payloads, it should be possible to create cable connections between a special VC switch panel and the payload. For that, direct communication with the payload is only needed during creation of the simulation context - later only indirect communication takes place over interface objects.

How the switches relate to signals to the payload can get defined inside the scenario file. The same with power supply connections.

With the second template parameter, we could make such connections possible, so it's only the rotation aspect... is it possible?

EDIT:
We had been talking about it:

http://en.wikipedia.org/wiki/JSC_Moon_Base

Maybe a good concept to play with.

 

[kulch]

First stage:
What should be an important aspect in the payload interface should be the capability to rotate an attachment point with its payload. Shuttle specific payload support structures (cradles) should be made part of the Shuttle itself.

Hardware which can get deployed, should have a line in the scenario file, how it is attached to the Shuttle (Up to 5 latches, all latches most be released for detaching the payload).

If rotating the attachment points is possible, this stage could be done with PM wrapped behind the VC, otherwise, we get in trouble.

Second stage: Connection to the VC.

For special payloads, it should be possible to create cable connections between a special VC switch panel and the payload. For that, direct communication with the payload is only needed during creation of the simulation context - later only indirect communication takes place over interface objects.

How the switches relate to signals to the payload can get defined inside the scenario file. The same with power supply connections.

With the second template parameter, we could make such connections possible, so it's only the rotation aspect... is it possible?

Why not? See PayloadManager_SDK.pdf, PM_SetSlotRotationAngles function. In terms of Payload Manager the orientation of slot defines the direction of jettisoning. The PM_SetSlotRotationAngles was intended for developing something like rotating rocket turrets or carrier catapultes.
I guess it is useful for Shuttle cradles.

 

[kulch]

On the SSU development, I can make a small pdf with what I think could be a good way to do the communication with the payload. It is not final or the other developers agree that it is good...

I'm making my own concept now (for Energia, Vulkan and other projects).
So it will be interesting to see yours like more complete and universal.

 

[Urwumpe]

So it will be interesting to see yours like more complete and universal.

It will still be pretty Shuttle specific, not universal. :sorry:

Making something universal is also not the goal - it's rather about making a payload connection for the shuttle, which represents the realistic shuttle operations well enough. The communication code could maybe get used again in the US Orbital segment of the ISS, as the hardware is very similar to the Shuttle, also a CEV project might find use for it (As it will be based on current hardware in design).

The goal for the communication system is to make something, of which we can reuse the code for a long time with minor updates - from the classic CRT VC to the never to be used CAU display format (which will be used in the CEV instead). With the connections being flexible enough for all the various hardware changes in the fleet - which is the hard part.

I only know the peak of the iceberg about the hardware differences between all orbiters and their changes over time - and it is a lot.

 

[Donamy]

It will still be pretty Shuttle specific, not universal. :sorry:

Making something universal is also not the goal - it's rather about making a payload connection for the shuttle, which represents the realistic shuttle operations well enough. The communication code could maybe get used again in the US Orbital segment of the ISS, as the hardware is very similar to the Shuttle, also a CEV project might find use for it (As it will be based on current hardware in design).

The goal for the communication system is to make something, of which we can reuse the code for a long time with minor updates - from the classic CRT VC to the never to be used CAU display format (which will be used in the CEV instead). With the connections being flexible enough for all the various hardware changes in the fleet - which is the hard part.

I only know the peak of the iceberg about the hardware differences between all orbiters and their changes over time - and it is a lot.

As far as the changes between Orbiters, we need only do what's reasonable. For instance, a pre MEDS cockpit would be nice, but it really doesn't change anything as far as the on orbit proceedures.

 

[Urwumpe]

As far as the changes between Orbiters, we need only do what's reasonable. For instance, a pre MEDS cockpit would be nice, but it really doesn't change anything as far as the on orbit proceedures.

The post-insertion and de-orbit preparation activities have some small changes related to the replacement of the DEUs (Display electronics unit) with the IDPs (integrated display processor). Also, the type of GPC used should have some effect - the loading times when changing the major mode/major function had been much longer for the shuttles before 1988.

 

[SiameseCat]

Instead of storing payload attachment data in the scenario file directly, it might be better to have a separate text file containing this type of data. The file name could then be a scenario entry.
I don't think we need to use PM: most of the features would not be used. Also, the scenario editor capability could cause problems if the user tried to edit the attachment point in-flight.

 

[Donamy]

The text or payload config file could be named after the mission, and could hold all pertinant info for the flight, launch date, elements, orbiter and payload.

 

[Urwumpe]

The text or payload config file could be named after the mission, and could hold all pertinant info for the flight, launch date, elements, orbiter and payload.

Yes, that could be included in a Mission Definition file, together with the I-loads. But in that case, a mission planning application would be helpful.

But I would suggest making the Orbiter only a verification value in the MDF, to make sure that the vessel gets created with a fitting mission definition file.