Flight Question XR5 Round-trip cargo delivery mission to Mars without refueling on difficult/realistic settings

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
1,924
Reaction score
340
Points
98
Location
Sparta
First, I can't reproduce the 1.72km/s delta-v for the eject burn to earth. The best solution I can find around the date 60616.5 is at least double the delta-v, around 3.450km/s.

You should be getting ~3.150 km/s from a ~150 km altitude parking orbit around Mars, which agrees with the trajectory planner's deltaV expenditure. Here is why:
The 1.72 km/s has an asterisk with the explanation: dv from C3 = 0 km²/s². C3 = 0 is equal to the escape velocity, which is √2 times bigger than your parking orbit velocity.
So if you want to calculate the dv for the Trans-Earth Injection burn:
DV _inj = 1.72 + √2*V_po - V_po , where V_po is the velocity of your parking orbit (assuming circular), in km/s.
For an altitude of 150 km above Mars' surface, your V_po is ~3.48 km/s so plugging in this number in we get: 1.72 + √2*3.48 - 3.48 = 3.16 km/s

This agrees with 288 day transfer from Mars to Earth -eject date on 60616.5- with a hyperbolic excess velocity of 4.45 km/s (oV in IMFD's Target Interecept program).
ApGykI.png
You can calculate the Injection dV from IMFD's oV (outbound Velocity?) with: DV_inj = sqrt(2*V_po² + oV²) - V_po, where DV_inj = injection deltaV, V_po = parking orbit velocity and oV = hyperbolic excess velocity from IMFD.
Plug in the numbers and you get : sqrt(2*3.48² + 4.45²) - 3.48 = 3.155 km/s

The second problem is that I can't find a return trajectory which aligns me for a direct entry for Cape Canaveral. The 'Map Method' (Delta Velocity course program combines with the map) doesn't work in this situation. I think it's because the return trip crosses earth's orbit before the real encounter. It seems to me this messes up the possibility to use the map method. Not sure though.

I am not sure what you mean with "a return trajectory which aligns me for a direct entry for Cape Canaveral". Any arrival at Earth with an equatorial inclination higher than 28.5° should be able to get you lined up with the Cape. If you are aiming for a day-side arrival and want to hit the atmosphere ~45°-60° away from the Cape, already lined up, it should be doable, but will take some refinement during the MCCs on the way back. There are some cases where this isn't possible, so you can try a night-side skip reentry, to get captured and land on your target when you are both on the day-side.
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
That's some great information. I'll try again! With regards to the base alignment, I did try to find an acceptable solution using the BaseApproach program at various moments on the way to earth, especially at g=0.01 and higher values, but I never found a solution. I think it depends a great deal on the exact moment of ejection. I'll keep trying, thanks.
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
Ok. I have done a few direct entries and landings now for the Mars-earth part. But I can't use the Reentry mode of the BaseApproach program. It just never gives a solution. So I used the orbit-insert mode which does give a solution. But still, it comes down to having to rely on luck. I don't understand where the periapsis is going to be and how I would make sure the base is somewhat downrange from there so I can do some aerobraking. I really like to understand how this should be planned. I feel like the exact moment is of major importance. But the trial-and-error process to find numbers which work is taking too much time and bores me out. If BaseApproach requires some gravity to be felt and can be used at a late stage only, how would I know the exact arrival-MJD of the Course program much earlier in time before ejecting? I can't figure this out.

Earth-Venus-Mars
Now I am practicing the slingshot. The burn takes about 1000m/s delta-v. NASA says 129m/s. I don't know if this has to do with the C3 again or it's me not doing it right.

I am using the Course - Planet approach program when approaching Venus. I set 5931 km for the PeA altitude as dictated by NASA (0.98 Venus radii). But I must also set EqI. And I have no idea what it should be. I have done a few tries without changing it. It did bring me to Mars, but I like to know how to check this number.

And I have the same arrival planning problem for Mars. BaseApproach isn't playing along. So I did the orbit-insert mode again. This time I wasn't lucky because the periapsis happened to be right over the base. I don't want to go around for one more orbit as this complicates things even further.

Any hints?

Edit: With some more experimentation, one container is delivered to Mars with enough fuel and lox left to make it back to earth. I think there's room in the delta-v budget for two containers at least.
 
Last edited:

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
The scenario is starting to take shape now. I post it once I feel the total amount of AIA Logistics containers aboard is maxed out.

The slingshot is down to about 500m/s by activating the Slingshot program ahead of the closest encounter with Venus, after using the Map method to steer towards the intended PeA and leaving the EqI setting alone. I am not sure if that is how it is supposed to be done, but if it works at a reasonable cost in terms of dv, I am totally fine with it.

And I managed a direct entry on Mars for Olympus with one 'go around orbit'. At the apoapsis of an -seat of the pants- eliptical orbit, BaseApproach does provide a solution without problems. So this part seems to be solved as well.


With regards to the deployment of empty consumable containers, there are a few things I'd like to agree on. For emmersive reasons, but perhaps also for a way to score such a mission between players, I'd like to hear your thoughts about the following:

I feel consumable containers should have some sort of deposit. Bringing them back to the surface of earth should return 100% of the deposit. Deploying them in stable low earth orbit should give something like 50% and deploying them in a destructive or unrecoverable fashion should return 0%. I am not sure in which unit to measure this. Maybe just asign a fictional amount of delta-v to them and sum it up with the remaining delta-v at the end of mission. This would give a total score.

Burning the main engines with the bay doors open feels bad. But the game allows it. Deploying empty containers while burning feels even worse. So I think it should be disallowed to have the bay doors open while using the main engines.

These are the settings I am working with now: MainFuelISP=1, LOXLoadout=1, LOXConsumptionRate=4, LOXConsumptionMultiplier=1.0, APUFuelBurnRate=2

Edit: I've pushed the XR5 all the way back to the edge of the runway threshold (RWY 15). And I am leaving the deck at a -very- late moment. Not even sure if the bumb at the end of the runway forces me airborne. If so, I am not sure if that's ok.

And containers can be deployed in any order, including going right through other containers. The current version of the XR5 empties containers in the wrong order, from the lower deck to the upper deck. I think it should be the other way aound. But that is how it is now.
 
Last edited:

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,031
Reaction score
1,271
Points
188
Location
Dallas, TX
As for getting off the ground so late, are you still having trouble rotating, or are you able to rotate but just aren't fast enough to get airborne yet? It may be that the bump at the end of the runway is forcing your nose up, but that in a nose up attitude you have enough lift. Try loading your heavier containers aft, light containers forward, in order to get your COG closer to the main gear.

As for aerobraking and once-around reentries, I've generally found, both in Orbiter and KSP, that a reentry from an escape trajectory in a winged vehicle lets you pick your landing site pretty much arbitrarily, so timing your arrival to occur at just the right time to hit your base isn't necessary.
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
As for getting off the ground so late, are you still having trouble rotating, or are you able to rotate but just aren't fast enough to get airborne yet? It may be that the bump at the end of the runway is forcing your nose up, but that in a nose up attitude you have enough lift. Try loading your heavier containers aft, light containers forward, in order to get your COG closer to the main gear.
It seems ignoring the maximum takeoff weight recommendation results in having trouble to get enough speed (which is fair). The rotate callout is at the very end as well. The heaviest container is the main fuel (13000 + 4000). The first fuel container is emptied during the takeoff roll. The containers are used in order from low to high slot numbers. And the low numbers are aft. So the COG moves forward during the roll and there doesn't seem to be a way to change that. I'll go with the heavy configuration now. In reality, a ramp at the end would solve this problem wouldn't it?

As for aerobraking and once-around reentries, I've generally found, both in Orbiter and KSP, that a reentry from an escape trajectory in a winged vehicle lets you pick your landing site pretty much arbitrarily, so timing your arrival to occur at just the right time to hit your base isn't necessary.
This did surprise me but is seems right. However, I still like to learn how to plan for a direct entry without a once-around orbit.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
5,031
Reaction score
1,271
Points
188
Location
Dallas, TX
It seems ignoring the maximum takeoff weight recommendation results in having trouble to get enough speed (which is fair). The rotate callout is at the very end as well.

If the rotate callout is at the very end of the runway, then it probably really is a weight issue and not balance.
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
Here's a short video of my takeoff:

I think it is ok after all.
Edit: I notice now there wasn't a rotate callout..
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
Interestingly, using the attitude control autopilot solves the problem. The fully loaded XR5 lifts off beatifully without the aid of the hover engines:
 
Last edited:

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,216
Reaction score
1,562
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
BTW the XR Attitude Hold autopilot uses elevator trim and/or RCS jets to maintain attitude, so that is what is helping to rotate the ship during takeoff.

As for XR cargo bay slots, it is by design that cargo slot numbers start with the lowest numbers on the bottom of the bay (1 2, 3, etc.), because the cargo bay code is common to all XR vessels with a cargo bay.

As a side note, there is no "minimum runway length" listed for fully-loaded XR vessels to take off, and so it is not a valid assumption that a fully-loaded XR5 should be able to take off from KSC using only elevators before running out of runway. However, you can always use hover engines and/or RCS when you don't have enough runway, as you have seen. :)
 
Last edited:

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
BTW the XR Attitude Hold autopilot uses elevator trim and/or RCS jets to maintain attitude, so that is what is helping to rotate the ship during takeoff.
Yes, I knew that. And it also controls the COG shifting. But I didn't expect this autopilot to be so effective compared to hover engine assist and normal control surface movements like pulling back on the stick (and those combined).

As for XR cargo bay slots, it is by design that cargo slot numbers start with the lowest numbers on the bottom of the bay (1 2, 3, etc.), because the cargo bay code is common to all XR vessels with a cargo bay.
Can you reconsider it? Just reversing the order for the XR5 would do. I think it makes sense that the topmost consumable containers are depleted and to be deployed first. I know it doesn't impact the delta-v if you deploy the bottom containers right through the upper ones, but for recording video, it would be nice if it would be the other way around.

As a side note, there is no "minimum runway length" listed for fully-loaded XR vessels to take off, and so it is not a valid assumption that a fully-loaded XR5 should be able to take off from KSC using only elevators before running out of runway. However, you can always use hover engines and/or RCS when you don't have enough runway, as you have seen. :)
That's totally fine. The documentation mentions a maximum recommended takeoff weight which makes sense for KSC.

Thanks for your great add-on! I am having fun with it for like a decade now and still getting better at it:
 
Last edited:

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,216
Reaction score
1,562
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Good point about the center-of-gravity shifting -- it is probably that which makes the biggest difference here.

Can you reconsider it? Just reversing the order for the XR5 would do. I think it makes sense that the topmost consumable containers are depleted and to be deployed first. I know it doesn't impact the delta-v if you deploy the bottom containers right through the upper ones, but for recording video, it would be nice if it would be the other way around.

I will add a TODO for the next XR patch releases -- it should be easy enough to drain the highest-numbered tanks first. Can't promise when the next patch release will arrive, though. :)
 

Marijn

Active member
Joined
Mar 5, 2008
Messages
755
Reaction score
166
Points
43
Location
Amsterdam
Ok, after lots of trial and error, I've managed to deliver seven AIA containers to Olympus base on Mars. And that seems to be the limit. Eight containers didn't work, then I have a 260 m/s deficit on the delta-v budget which makes the return trip to earth seriously problematic (my estimation for the return trip is 7500m/s). Delivering seven containers did leave me with a comfortable 400 m/s delta-v left.

Here's the config override file: https://pastebin.com/ArzmRjMe
And the scenario file: https://pastebin.com/RJyHAvWq (the Course program is set up, anyone without IMFD installed should delete the contents of BEGIN_MFD Right).

I've been using APUFuelBurnRate=2 (110 minutes). I think it's possible to raise it to 3 (74 minutes).

There's one thing I like to improve upon and that's the use of the RCS thrusters during reentries by the XR autopilot. It fires short bursts continuously to keep the nose up. I tried putting the cargo containers all the way in the back, but that didn't solve it. Except for the fuel savings, the sound of the thrusters is a bit glitchy on my end. I am using XRSound 1.00. Small bursts with the Ctrl button pressed are inaudible.

These are the optimizations:
-Launching from runway 15 instead of 33 (smaller turn towards 90 degrees) and with the vessel placed against the runway threshold
-No orbit circularization; once out of the atmosphere, I did drop the empty fuel containers and did the burn to eject to Venus without raising the periapsis.
-250 m/s slingshot at Venus at G=0.5 (after this point, the required delta-v seems to go up)
-At Mars arrival, I used the BaseApproach program using the Orbit-Insert mode
-During capturing, I used the Map program to maintain base alignment by rolling the vessel over. In the final stages when the apoapsis drops below 1000 meters,, I used BaseSyncMFD for final alignment.
-At apoapsis after being captured, I did a small prograde burn at apoapsis (200km) to make it to Olympus.
-At base arrival, I flew the XR5 to below 400m/s IAS before engaging the Hover and Retro engines.

To prevend crashes at high time compression, I deleted any empty containers using the scenario editor.
 
Top