Discussion Orbiter Beta - Multistage and Docking options

[fred18]

Hi all,

as all of you know I'm finishing also the new multistage for the new fantastic orbiter Beta.

I will use the very same concept used for 2010, so no big difference is planned.

Anyway, just to discuss, Orbiter Beta actually allows now for a big different approach if desired: the possibility to have multiple stages docked one to the other, since now docking is allowed also on ground.

I am wondering, and would like to know your point of view, what, for a multistage launcher, are the advantages of this approach and what could be the downside.

As a very first thought I can think of

Advantages:
- more realism in general since the single stages or elements composing a launcher will work by themselves as in reality
- more smooth staging visuals since the jettisoned stage is not created anymore at the instant of staging, but is already there, it's just detached (this was achievable also with attachments, as velcro did)
- easier coding for physical parameters, since each stage can be coded by itself and then by docking orbiter will calculate the rest (thrust composition, weight composition etc)

Downsides:
- the main downside that I see is that all the parameters that relies on "vehicle" performance will have to be changed taken into consideration the stack vehicle and not just the vehicle. This means to get the handles and the interfaces of all the docked vehicles, get their parameters, calculate the stack parameters and use them.
- So coding guidance and control might become more difficult, surely for a "general" multistage module
- the dock must be deleted when a stage is jettisoned otherwise we will have a mess of docking ports on our vehicles.

What do you guys think?

Again, I'm not changing the concept of multistage for now, it's just a question to discuss and see your point of view


Fred

 

[Urwumpe]

Well, I see it equally two-sided. For the SSU context, it would be mostly useless, though the possibilities regarding soft and hard docking are sure interesting now.

But then: For defining the launch stack, it makes no sense, especially since I am pretty sure that aerodynamics are not simulated, and thus, the current attachment based approach is good enough, especially since we have already accurate models there.

But for payloads on the other hand, it could make a lot of things easier, since it means that track the payload mass and CoG could be delegated to Orbiter then. Also it could make the crawler motion model simpler.

But I really see its advantages in orbital flight and assembly right now. Maybe also some selective tasks on the ground.

For a current concept project, I could for example imagine attaching ground mobile habitat stations to a landed spacecraft and move the spacecraft with the habitat stations over the terrain.

I see no problems with the mess of docking ports right now, its likely better to have a vast number of docking ports even if most are no longer needed, than to risk scenario file corruption.

 

[4throck]

Yes, docked vessels makes sense if you are doing something like the LEM or Soyuz entirely using multistage and vessel scripts. Don't see why not.

Of course you can go all the way docking rocket parts and them somehow managing them as stages. But I wouldn't go there, Kerbal already does that very well.

 

[fred18]

I agree: I think the most benefit is for other type of vehicles: for example arrow can land with other vessels docked in its bay, I can think of the 747 carrying the shuttle on its back which simply will require a docking port and no other coding etc.

I see no particular benefit for launchers, as mentioned above.

especially since I am pretty sure that aerodynamics are not simulated

I didn't get this clear, aerodynamics are simulated, aren't they?

 

[boogabooga]

From the standpoint of someone who does a lot of BEO stuff, No.

Advantages:
- more smooth staging visuals since the jettisoned stage is not created anymore at the instant of staging, but is already there, it's just detached (this was achievable also with attachments, as velcro did)

The problem with velcro is that the stages are separate vessels. Some popular MFDs need to be set up on the ground (IMFD and the TransX/LaunchMFD combo, for example). You lose your MFD instance when the vessel switches focus during staging. This means you have to enter your solution multiple times. It is much easier if you can do your departure burn with the same vessel that you launch from.

(Setting the MFDs in the last stage and shifting focus to the first stage for launch has drawbacks as well if timing the launch is really critical).

The point might be moot if none of the said MFDs work in Orbiter2015 beta anyway.

 

[4throck]

One interesting usage of ground docking would be using something like IMS to do a surface base, with power, temperature and consumables. I tried that once and it works more or less. But it has potential!

You could also have rovers that docked with such bases (eliminates the need for EVAs ).
With terrain all this becomes interesting ;-)

 

[Urwumpe]

I didn't get this clear, aerodynamics are simulated, aren't they?

Well, do you think honestly Orbiter will simulate the two attached vessels as one aerodynamic body?

 

[fred18]

Well, do you think honestly Orbiter will simulate the two attached vessels as one aerodynamic body?

Ah now I see what you mean! No, sure, I think aerodynamics will be simulated individually for each vessel and then resultants will be simply added due to docking.

This can be partial (only very partial!) acceptable for sidemounted vehicles, but for sure not for inline... each stage will generate drag and all the drag vectors will be added one to each other... definitely not working!