Project SpaceX SuperHeavy

[Marijn]

Allrighty. In a single take: Launching two Tankers twelve seconds apart. Catching both boosters. Tanker_1 goes into an 200x220km orbit, Tanker_2 into 200x202km and therefore catches up. Then aligning Tanker_2 with a small anti-normal plane change at the ascending node shortly after both ships meco'd and an orbit sync manouver using RCS retro translation.

The default prograde, retrograde etc. ap's are a bit overshooty. I use killrot to help it a bit. At other times I time-compress over it knowing I'll be dumping fuel anyways later.

At redezvous, I used both ships default prograde AP's to maintain a predictable position. Then set up PursuitMFD to control position relative to the docking port, but not attitude (disabling HLD). After positioning, I rolled the ship over manually for the back to back docking and also controlled attitude manually with RCS rotation until final docking.

Then a fuel transfer, undocking, de-orbit, reentry and landing. No base alignment necessary. The reentry AP is able to correct for that.

Great work!

 

[BrianJ]

Great vid - thanks!
You got the docking looking pretty slick - a combination of manual attitude control and PursuitMFD for position (yes?).
Must try it.
I wonder why PursuitMFD wont handle the attitude (I thought it could).
Anyway, I enjoyed the vid. Cheers,
Brian

 

[Marijn]

a combination of manual attitude control and PursuitMFD for position (yes?).
I wonder why PursuitMFD wont handle the attitude (I thought it could).

PursuitMFD can handle attitude. But the problem is, PursuitMFD will bring pitch, yaw and roll to 0. But that doesn't give the desired orientation. This is what happens then:


PursuitMFD is in docking relative mode and pitch, yaw and roll are zero'd. (Also, rZ=29.09 seems offset by 10 because pZ was set to 20.00)


So to have the correct orientation, what I did was engaging the default Prograde autopilots of both ships shortly before docking so their attitude is almost fixed relative to each other:


I did disable PursuitMFD's attitude control by clicking HLD after APD (no more display of HOLD in blue). According to PursuitMFD, yaw=-180 now.



Then roll the ship 180 degrees over manually to align the docking ports:


From now on, attitude needs to be controlled manually. Pitch is -180 now and yaw is 0.


With the previous docking method, no such tricks were needed. Maybe the docking port is currently facing backwards or something like that?

 

[Marijn]

The source tank selection works good btw. Thanks for that.

 

[BrianJ]

Hi,
yes, that's what PursuitMFD does for me too, if attitude control is enabled.
There shouldn't be a problem with docking port direction, given a correct definition of the port.
For back-to-back docking of two identical vessels, the docking port HAS to be pointing in the +Y axis.
I'll try some experiments to see if I can figure out whats going on - I feel PursuitMFD should be able to handle the docking.
Cheers,
Brian

 

[Marijn]

Ok. I'll do some experiments as well. I think the XR5 presents the same situation. I'll check how PursuitMFD deals with that.

 

[Marijn]

Using the XR5, PursuitMFD can do the docking. The Tanker is in Prograde orientation. The nose is pointing backwards as well compared to the first screenshot in the previous post. But unlike Tanker_2, the XR5 is pointing the top towards Tanker_1.




Not sure what that could mean though. I'll try docking two XR5's later to see what happens then.

 

[Marijn]

Docking two XR5's in the same way results in this (the ship in the foreground is oriented prograde)


Can you compare the port orientation of the Starship/Tanker with the one in the XR5?

 

[BrianJ]

Hi,
well, I couldn't see the XR-5 dock parameters in the docs anywhere, so I just tried the simplest thing - reversing the dock rotation parameter from:

0 4.545 0   0 1 0   0 0 1

to:

0 4.545 0   0 1 0   0 0 -1

and it seems to work for PursuitMFD!
Attached patch zip has modules for starship, starship_2, tanker, tanker_2, with updated dock parameter.
Give it a try.
Cheers,
Brian

 

[Marijn]

and it seems to work for PursuitMFD!

Yup, confirmed. PursuitMFD plays nicely now. Well done!

 

[Cosmic Penguin]

A question for Brian - I was trying to make a 2nd Starship launch pad at KSC LC-39A using your "double Starship launch" scenario, but the pad and Starship ended up at dangerous angles with respect to the ground like the Leaning Tower of Pisa. What did my scenario went wrong I wonder?

Thanks!

 

[BrianJ]

Hi,
if you switch focus to BC_TOWER2, open up Scenario Editor, go to Location tab, click Apply - that should straighten it up for you.
Then you need to save the scenario and edit it to change the BC_TOWER2 Alt entry to 0.
See attached .scn file

 

[Pioneer]

Hi Brian,
Thank you very much for your work on this great addon! I've been trying to do an aerobraking at Mars, and it seems that whenever I utilize the included AoA and Bank autopilot, the Bank values seem to reset and the spacecraft wants to roll fully over once the AoA goes from either positive to negative, or the other way. My point of reference is the XR bank and attitude autopilot which doesn't exhibit these behaviors. This is causing me issues with properly completing my aerobraking maneuvers.

 

[BrianJ]

Hi Brian,
Thank you very much for your work on this great addon! I've been trying to do an aerobraking at Mars, and it seems that whenever I utilize the included AoA and Bank autopilot, the Bank values seem to reset and the spacecraft wants to roll fully over once the AoA goes from either positive to negative, or the other way. My point of reference is the XR bank and attitude autopilot which doesn't exhibit these behaviors. This is causing me issues with properly completing my aerobraking maneuvers.

Hi,
I don't really understand the precise nature of the problem, could you explain what happens in more detail or post a scenario?

the Bank values seem to reset

It resets to 0?

the spacecraft wants to roll fully over once the AoA goes from either positive to negative

I'm not sure I ever considered that a negative AoA would be required! That might be the cause of any problem.

Anyway, I can't remember how I coded the AoA/Bank autopilot, so I'll have to have a dig around

Cheers,
Brian

 

[Pioneer]

Hi,
I don't really understand the precise nature of the problem, could you explain what happens in more detail or post a scenario?


It resets to 0?


I'm not sure I ever considered that a negative AoA would be required! That might be the cause of any problem.

Anyway, I can't remember how I coded the AoA/Bank autopilot, so I'll have to have a dig around

Cheers,
Brian

Hello Brian,

Perhaps these images will help illustrate the problem:

 

[BrianJ]

Hello Brian,

Perhaps these images will help illustrate the problem:

Hi,
I had a quick look at your images and my first thought is that it is the negative AoA that is causing a problem.
(negative AoA means airflow is impacting the upper surface of the spacecraft, not heatshield).
In the first image the commanded AoA is -2.4 and Bank 20.2 .....but the attitude looks like AoA +2.4 and Bank (180 + 20.2).

I'll have a look in the code, but in the meantime - can you avoid the problem by using only positive AoA command?

Cheers,
BrianJ

 

[BrianJ]

@Pioneer
Thanks for the heads-up.
It was a coding error.
The code intended to restrict the FBW-Reentry commands to +ive AoA was actually resetting the Bank to 0.
Now it works as intended, so the FBW_Reentry AoA is restricted from 0 to 90 (in fact its 0.1 to 90, to avoid nasty vector singularity at 0).
I did try to make -ive AoA available, but the autopilot doesn't behave well going from + to -.

New starship and tanker .dll modules are in the attached .zip pack below.
Best I could do - hope it works for you.
Cheers,
BrianJ