Question O2016 and using docking ports for rocket assembly

[N_Molson]

Hello,

I was wondering if there is a way to use docking ports to attach rocket stages ? I know it was a strict no-go in O2010, but have not been following closely Orbiter development those last years.

Just to be sure, else I'll write my launcher in the old-fashioned way (attachment points and "manual" collection of attached modules parameters).

Oh and of course, I've tried. I want to attach 4 boosters to a single core. For some reason, 1 of the boosters "docks" correctly on scenario load, but not the 3 others. Also the whole stack sinks under the ground. Same scenario in orbit works perfectly, boosters dock as they should.

 

[GLS]

AFAIK, the big trick is when time comes for separation, you have to undock the vessels and delete the docking ports, to prevent re-docking. You should look at the stock Atlantis as it uses docking ports to attach the ET and SRBs.

 

[N_Molson]

AFAIK, the big trick is when time comes for separation, you have to undock the vessels and delete the docking ports, to prevent re-docking.

Maybe separate in post-step, then delete the docking port in next frame pre-step ?

Yes it seems stock Atlantis does that in 2016, that's why I'm asking. Though the Atlantis code sample is way over my head, with variables shared between classes.

 

[N_Molson]

OK I tried to dock the boosters inside the simulation, with the Scenario Editor. When I dock a module to the core booster, they immediately both sink into the ground.

 

[GLS]

Maybe separate in post-step, then delete the docking port in next frame pre-step ?

Yes it seems stock Atlantis does that in 2016, that's why I'm asking. Though the Atlantis code sample is way over my head, with variables shared between classes.

Yeah, separations should always occur in one of the time step functions (don't remember which one ?‍ ) because of state propagation.

About the touchdown points, maybe only one of the docked vessels defines them, or only one docked vessel can be touching the ground... it should be in the stock Atlantis code. Anyway, you can define the touchdown points only in the core, and only define them in the boosters after sep (or not at all).

 

[N_Molson]

Ok there is something weird going on...

Using the Scenario Editor and pausing the scenario, I managed to assemble the rocket on the ground, pointed up as it should be. I can even unpause the scenario, and it stands still. As soon as I apply some thrust, the whole thing sinks into the ground (we have TWR <1, so it should stay where it is).

If I save the scenario with the stack assembled, it breaks up on reload. Very weird. I used Atlantis SRB nav vertex definitions for touchdownpoints, so I have valid convex collision models...

 

[Urwumpe]

Ok there is something weird going on...

Using the Scenario Editor and pausing the scenario, I managed to assemble the rocket on the ground, pointed up as it should be. I can even unpause the scenario, and it stands still. As soon as I apply some thrust, the whole thing sinks into the ground (we have TWR <1, so it should stay where it is).

If I save the scenario with the stack assembled, it breaks up on reload. Very weird. I used Atlantis SRB nav vertex definitions for touchdownpoints, so I have valid convex collision models...

That behaviour is a known error in Orbiter for some time, if you have 0 << T/W << 1, the spacecraft will sink into the ground, because the vessel state switches from landed to orbiting. Strangely, it works fine the other way around, a powered landing at T/W ~ 1 is no issue.

 

[N_Molson]

hmm... I'll try to make the core module create and dock the boosters... seems Atlantis does something like that...

 

[n72.75]

NASSP is slowly moving in the direction of all docked stages. Apollo 5 now uses all docked stages if you want to take a look at how we do it, in the latest build.

 

[N_Molson]

NASSP is slowly moving in the direction of all docked stages. Apollo 5 now uses all docked stages if you want to take a look at how we do it, in the latest build.

Thanks, but the Saturn is an "inline" launcher, I'm trying to attach 4 boosters around a core.

 

[N_Molson]

So, a couple of months later, I'm still having the issue... Different launcher but still 1 core tailsitter with 4 strapon boosters, so similar configuration...

When I load only the core in the scenario, no problem, it sits idle on the pad, pointing towards the stars as it should.

When I load an upper stage docked to the core in a similar scenarios, the assembly starts sinking into the ground as the scenario starts, then bounces randomly around.

Note that in the present case, the second stage is a mere config file with a static mass of 8000. No touchdownpoints defined. Can't be simpler. And still, it fails.

With Energia 5, I went around the issue by having the core stage creating and "propagating" the "child" stages. But this is messy and means the user can't do anything about the launcher configuration in the scenario file, as it is "hardcoded" in the .dll. It also means plenty of variables have to be stored in order to "rebuild" the rocket in its saved configuration.

I want to use docking ports for assembly because stock Atlantis does it (which proves its possible) and because center of mass shifting is done automatically. I looked at the code (I spent hours on it) but it has so many dependancies I don't understand it is pretty useless to me.

Please help.

 

[GLS]

Add those 8000 (kg?) to the core and load it without the upper stage. If it sinks, then you need to tweek the parameters of the touchdown points. If it works... then I'd call a witch...

 

[N_Molson]

Well I tried the other way and made the core stage 0.1 (kg, yes). Same result. We can safely assume that 100 grams make no noticeable difference.

My scenario looks like this, H5-1 is the first stage (total mass = 175,000 kg) :

BEGIN_SHIPS
CZ5-H5-1:CZ5_H5_1
  STATUS Landed Earth
  BASE Cape Canaveral:5
  HEADING 90
  PRPLEVEL 0:1
  DOCKINFO 0:1,CZ5-H5-2
END
CZ5-H5-2:CZ5_H5_2
  STATUS Landed Earth
  BASE Cape Canaveral:5
  DOCKINFO 1:0,CZ5-H5-1
END
END_SHIPS

In the first stage .dll I have :

static const int ntdvtx = 4;
static const TOUCHDOWNVTX tdvtx[ntdvtx] = {
    {_V(0, 10, -15), 1e8, 1e6, 3 },
    {_V(8.666,-5,-15), 1e8, 1e6, 3 },
    {_V(-8.666,-5,-15), 1e8, 1e6, 3 },
    {_V(0, 0,15), 1e8, 1e6, 3 },
};

And the second stage is a .cfg file such as :

; === Configuration file for the International Space Station ===

Meshname = CZ5_H5_2
Mass = 0.1
Size = 2.5

; === Docking ports ===
BEGIN_DOCKLIST
0 0  0   0 0  1    0 1 0
0 0  0.233   0 0 -1    0 1 0
0 0  3.655   1 0  0    0 1 0
0 0  3.655   1 0  0    0 -1 0
END_DOCKLIST

Another thing : are the stages listed in the right order ? Because the order seems to have a consequence in simulation (I get sink and/or random bounce in both cases...).

 

[N_Molson]

Maybe I could set the core stage position at fixed coordinates each simulation frame ? Is that even possible ?

 

[Urwumpe]

Maybe I could set the core stage position at fixed coordinates each simulation frame ? Is that even possible ?

No, why should you anyway?

I think the main problem is that you produce an instability in Orbiters physics engine that way, because your spring force parameters are either too stiff or too loose.

 

[N_Molson]

I think I found a way... creating a launchpad that is super-heavy (and stable), then docking the first stage to it, and so on... The problem was the delta between the rocket stage CG and the touchdownpoints... when that delta is too high things are unstable. The launchpad CG is set very close to the contact points, which solves the issue. The extreme mass of the pad makes things stable : docking extra rocket stages to it does not move it significantly.

The trick is to put the "child" stages in orbit (after all the sim name is Orbiter !!) ; if landed they start the simulation in a "frozen" state, and it takes seconds before they are updated and actually dock. That trick works, the stages immediately teleport to the launchpad and dock in the order set in the scenario (this is critical). The small side effect is that XRsound greets me with a "subsonic" callout and bang (you bet, the stage has been teleporting at supra-luminic speed !!). But that can be deactivated.

Next step is to add a condition to "undock" when first stage is at max thrust (and it should do so only if the boosters are themselves at max thrust) ; and I think we'll be out of the woods !

 

[ChrisRowland]

I'm a newcomer to all this and, knowing no better, docked a Starship on top of a booster.

The scenario looks like this:

BEGIN_SHIPS
SuperHeavy:test\superheavy
STATUS Orbiting Earth
RPOS 5730967.196 2594657.904 1007002.294
RVEL 7.8990 -166.1026 383.0408
AROT 69.981 -65.009 -7.136
VROT -0.0026 -0.0011 -0.0750
AFCMODE 7
PRPLEVEL 0:1
DOCKINFO 0:0,StarshipSN8
NAVFREQ 580 0
TGT LZ1
NUMRAP 28
END
StarshipSN8:starship_sn8\starship_sn8
STATUS Orbiting Earth
RPOS 5731015.034 2594678.856 1007009.928
RVEL 7.8995 -166.1045 383.0424
AROT 69.981 -65.009 -7.136
VROT -0.0026 -0.0011 -0.0750
AFCMODE 7
PRPLEVEL 0:1.000000 1:1.0 2:1.000000
DOCKINFO 0:0,SuperHeavy
NAVFREQ 0 0
CAN 0.0000 0.0000
WNG 0.0000 0.0000 0.0000
LEG 0 0.0000
THR 0.0000 0
AUT 0 0 0 0 0
TGT NULL
END

This isn't attached to the ground but is in contact with it. There is a docking port on top of the booster, looking up.

It works to the extent that my booster is aware of the mass of the starship and the whole edifice is currently uncontrollable.

The booster shows promise on it's own, I've got it to do a flip, a boostback burn, entry and landing, ending up a few hundred metres away with no guidance other than adjusting the boostback burn to aim a little short of the target.

Chris

 

[N_Molson]

It works to the extent that my booster is aware of the mass of the starship and the whole edifice is currently uncontrollable.

What you have to do is to implement some thrust vectoring, should help a lot. Now I'd add bigger airfoils to the lower booster because else your lift center will be dangerously forward, and this tends to make any aircraft uncontrollable (especially in your case the top rocket has quite big airfoils). The center of lift should be (slighlty) behind the center of mass.

 

[ChrisRowland]

I've got invisible RCS thrusters, quite powerful ones, equivalent to 4 of the main engines vectored by about 10 degrees. But it's all a bit like balancing a pencil on your finger. Am working on an autopilot.

It it isn't going fast enough for aerodynamics to be a feature yet, it barely lifts off.