what happens when you actually enter the PEG-4 parameters?
Left real weight, center heavy weight.
REI Ok
Which we do, because we don't target anything using PEG-7, so we have no EI point
By adding the expected burn time (oms_burn_target.burn_time_duration) into the rei correction, it seems to be an acceptable approximation for the REI (?)
I tried it on different entry deorbit scenarios.
- Code: Select all
if (oms_burn_target.peg4 == 0) # need to estimate REI
{
#print("Extrapolated state reduced vel: ", v[0], " ", v[1], " ", v[2]);
var rei = SpaceShuttle.get_rei(r,v);
# correct REI for empirics and time to interface
var rei_correction = 375.0 + 3.6556 * periapsis_nm;
rei_correction = rei_correction - (oms_burn_target.time_to_burn + oms_burn_target.burn_time_duration) * norm(v) * 0.000164578833693;
# also Earth rotates while we coast, this is very naive
var lat = getprop("/position/latitude-deg");
var rot_correction = math.cos(math.pi * lat/180.0) * 465.0 * (oms_burn_target.time_to_burn + oms_burn_target.burn_time_duration) * 0.000539956803456;
oms_burn_target.rei = rei + rei_correction + rot_correction;
}
Still the weight issue affecting the Perigee hence the REI for the left picture that we can disregard as the targeted Perigee is false ( but 22 Nm ish of Perigee really expected gives the REI expected by PEG4 in the right picture)
*For the weight thing, I might have found something interesting.
I never really noticed it before because of the small burn duration differences weightwise for a 200 Nm Orbit. It does matter much more at 500 Nm with burn time going from 7:30 up to 8:30 with a 30000 pounds difference.
I looked then for a burn time variable in the Oms_burn_future computations as Targeted Apsis computations are not affected by weight/accel for an instantaneous burn withtout TIG.
In oms_burn_logic, that line adds a burn_time --> accel --> weight dependency for a forecasted burn computations and might be at the origin of the Perigee discrepancy observed.
- Code: Select all
SpaceShuttle.targeting_manager.set_evolution_time(time + burn_time + 10.0);
Just for a rough test, I removed the line above fixing the max_evolution_time to a constant 8000 in the targeting manager hash.
And it works out ok.