Flight Question Distance traveled during deccelaration burn question.

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
2,021
Reaction score
623
Points
128
Location
Sparta
Hi everyone,

I've been using the method shown in the Orbiter tutorial "DG to the Moon", to calculate how far away from base i should start my deceleration burn:

t=v/a

x=vt-1/2at²

x= distance travelled (m)
t= time of burn (sec)
v= Original speed (m/sec)
a= deceleration (m/sec²)

It works pretty well, but the problem is that it doesn't take into account the change of the deceleration due to the change in mass (fuel used for the burn).

I already know how to calculate the fuel consumption rate of an engine. (kg/sec) - (thank you again Mindblast) :thumbup:

Can someone show me an equation that takes this into account?

:cheers:

(sorry for the typo in the headline)!
 
Last edited:
Well there's a set of equation which takes momentum (so is mass) into account, but every variation of it will involve integrals, shall we advance?
 
Well there's a set of equation which takes momentum (so is mass) into account, but every variation of it will involve integrals, shall we advance?

Yes please.

BurntimecalcMFD shows you this (the Delta-S parameter). If you want the equation, then look in the BTC code.

I can't get the BurntimecalcMFD to work in the Orbiter 2009 beta, but i'd also like to know how to calculate this myself. I'll look in the code though, thanks.
 
ok... First of all, I'm sorry with my rusty physics (because I'm studying Medicine now) basically what happens is...

dp/dt = F

and from F you can take the decceleration and the p is momentum

since momentum (p) = m.v

then...

if we define Y as the change of mass in second then

int Y dt = m and p = m.v so p = v . int Y dt

so you just have to take that into account but rememer that my skill is rusty so it's better if you rework it yourself or ask other people who are studying physics or engineering or any other subject related
 
I'm just a computer scientist so i'm not an expert on this field either... however i'd take the following aproach:

[math]x = \int v(t)\,dt[/math]
[math]v(t) = v_{initial} - \int a(t)\,dt[/math]
[math]a(t) = \frac{F_{thrust}}{m(t)}[/math]
[math]m(t) = m_{initial} - \dot mt[/math]

so

[math]x = \int v_{initial} - \int \frac{F_{thrust}}{m_{initial}-\dot mt}\,dt\,dt[/math]

And at this point i'm chewing on how to integrate the term of the second integral. :hmm:
 
@Mindblast, you forgot to add the second integral, because there are 2 ds, there should be two worms (lol) and dt dt can be written off as d^2t right?
 
[math]x = \int v_{initial} - \int \frac{F_{thrust}}{m_{initial}-\dot mt}\,dt\,dt[/math]

And at this point i'm chewing on how to integrate the term of the second integral. :hmm:

The general form of [math]\int \frac{a}{x}\,dx[/math] is = [math]a\log(x)[/math]
 
ok... First of all, I'm sorry with my rusty physics (because I'm studying Medicine now) basically what happens is...

dp/dt = F

and from F you can take the decceleration and the p is momentum

since momentum (p) = m.v

then...

if we define Y as the change of mass in second then

int Y dt = m and p = m.v so p = v . int Y dt

so you just have to take that into account but rememer that my skill is rusty so it's better if you rework it yourself or ask other people who are studying physics or engineering or any other subject related

Thank you for taking the time to answer my question and also for pointing me in the right direction.

Strange. It works fine in mine.

Yes it does! (Now that i'm using v1.5 instead of the 1.42 that i had) :embarrassed:

But -although this is an excellent add-on and i've used it for a long time- lately, i find myself preferring to make things a little more interesting by trying to find things out for myself.

This brings up a topic that i'd like to discuss.

Consider this mission for example:
a) I take off from the Cape in an (awesome) DGIV.
b) I use the PRO903SPEC90 Autopilot to make an ascent to Mir. (all i have to do is to time it correctly)
c) When in LEO instead of doing the nessecary plane alignment and orbit sync i use the IMFD to set up a rendezvous with Mir sometime in the next 30 min to 1 hour (hit AB, sit back and enjoy the view.)
d) As soon as i approach the station, i hit AB in the Match Speed tool of the same MFD and then use the Autopilot for Docking.
e) A few minutes later voila! Docked! But did I ACTUALLY FLY that mission or just went along for the ride?

It's not that i have anything against autopilots or easy-to-use mfds, i use them quite often. (Many-many thanks to all the developers for all their hard work). It's just that sometimes things get TOO easy to be any challenge at all.
 
I use reentry mfd for decelerating to a base. This is for any base whether on the moon or custom bases at any airless rock in orbiter. With wings level, I increase the retro burn to get my deceleration to match the required deceleration in reentry. Then a bit of nose down as needed to offset the descent to make it gradual. No need for LOLA or anything automated. Just the required deceleration as shown in reentry. But remember that the actual deceleration for the deltaglider for example is only 3 to 4 m/s/s depending on mass so you need to onsider starting the deceleration burn when the required deceleration is somewhere between 2 and 3 m/s/s.
 
I would just estimate it:
1. Determine how long it would take to decelerate from speed, given current acceleration potential of the engine
2. Determine how much fuel would be used during that burn
3. Calculate what your acceleration potential will be after burning off that fuel
4. Using the average of the current acceleration potential and the final, again calculate how long it would take to decelerate
5. Repeat steps 2-4 as desired. For most flights, the answer should be "accurate enough" without needing to repeat the calculation. Note also that each time you repeat the calculation, you will improve the accuracy by less than you did the previous time.

Edit: You want the distance during deceleration. For this, just multiply the time calculated in step 4 by the average of your initial velocity and your expected velocity after the burn.
 
Last edited:
I want to thank all of you that posted answers to my question.

@ Hielor: That's a pretty good method, and it gets the job done, but i'm looking for something more accurate. You see i want to try and make a direct descent to the the lunar surface without doing a LOI burn first and without using any mfds.

@ flytandem: This is something like i've been doing so far, without the reentry mfd though.

@ Eccentrus, Mindblast and EtherDragon.
Sorry guys, i thought i could handle it, but it turns out that these equations are beyond my skill-set.

As i did a little more research, i found these equations from the manual of washington kuhlmann's equation MFD:

DV=LN((ms+ml+mi)/(ms+ml+mf)))*Isp (Fuel consumption for a given speed change).
tbn=(mi-mf)*Isp/THRUST (Burn time calculation).


DV = Speed Incr/Decr (m/s)
ms = Ship mass (kg)
ml = load mass (Kg)
mi = Initial fuel mass (kg)
mf = Final fuel mass (kg)
Isp = Specific Impulse (m/s)
THR= Thrust (N)

My questions are:
1. Is the following method correct?
a) Solve the DV equation for the mf variable (since all the other variables are known).
b) Use the result in the tbn equation to get an accurate burn time.
c) Use this burn time as t in the x=vt-1/2at² equation but replace (a) with (v/t) (since t=v/a). This way the distance would be x= vt-1/2(v/t)*t²=1/2vt (where t= the burn time).


Again, thank you in advance.
 
Last edited:
@ Hielor: That's a pretty good method, and it gets the job done, but i'm looking for something more accurate. You see i want to try and make a direct descent to the the lunar surface without doing a LOI burn first and without using any mfds.
Ah but! Using that method, you can be as accurate as you want by simply repeating the process. This is basically Newton's Method.

However, you're also failing to take into account the acceleration due to gravity, so you'll need to include that if you're going for 100% accuracy (and remember that it will increase as you get closer to the ground).

Realistically, though, you don't want 100% accuracy for this to figure "if I start a full-thrust burn now, I should stop right at the lunar surface" because more likely than not you'll end up smashing into the ground instead. You want to give yourself a margin, say 10-25km, and then you start the burn at full throttle and adjust later, so you're using less than full throttle toward the end.

If tat makes sense...
 
You will never turn a hyperbolic orbit into a circular orbit, with any reasonable efficiency, without dynamic throttling and attitude change

Get Ecc. < 0.50 and use the Oberth effect to burn each time at PeA.

When Orbiter2009 is released we can do all these calculations in advanced, and then write a script to preform maneuvers.
 
Ah but! Using that method, you can be as accurate as you want by simply repeating the process. This is basically Newton's Method.

However, you're also failing to take into account the acceleration due to gravity, so you'll need to include that if you're going for 100% accuracy (and remember that it will increase as you get closer to the ground).

Realistically, though, you don't want 100% accuracy for this to figure "if I start a full-thrust burn now, I should stop right at the lunar surface" because more likely than not you'll end up smashing into the ground instead. You want to give yourself a margin, say 10-25km, and then you start the burn at full throttle and adjust later, so you're using less than full throttle toward the end.

If tat makes sense...

:tiphat: Actually it makes a lot of sense! You are right, i got too hung up on doing a "full-thrust burn now, so I should stop right at the lunar surface" that i didn't take the other variables in account. I was hoping to compensate for the gravity with a little hover power or with a little bit of pitch during the deceleration burn but i don't know any way to estimate the fuel required for that.

---------- Post added at 09:23 PM ---------- Previous post was at 08:31 PM ----------

No need for LOLA or anything automated. Just the required deceleration as shown in reentry.


LOLA is exactly the... "effect" i want to reproduce without the automation.
(That lunar landing looks SO cool!)

I'm new in the community, but from what i've seen from posts here and in the hangar... the original author is not "among" us anymore...? (Or did i just ask another stupid -and macabre- question?)
 
Last edited:
@Mindblast, you forgot to add the second integral, because there are 2 ds, there should be two worms (lol) and dt dt can be written off as d^2t right?

Well yes they are meant to be nested.. like:

[math]x = \int ({v_{initial} - \int ({\frac{F_{thrust}}{m_{initial} - \dot mt}})\,dt})\,dt[/math]

I just found a really cool tool for doing integrations: http://integrals.wolfram.com/index.jsp :thumbup:

That helped me to integrate the inner term to [math]-\frac{F_{thrust}*log(m_{initial}-\dot mt)}{\dot m}[/math]

Unfortunately it gets pretty complicated when i then try to do the integration for the outer integral... the above leads to:

[math]v(t) = v_{initial} - \frac{F_{thrust}(log(m_{initial}) - log(m_{initial} - \dot mt))}{\dot m} = v_{initial} - \frac{F_{thrust}log(\frac{m_{initial}}{m_{initial} - \dot mt})}{\dot m}[/math]

setting this to 0 gives the time needed for the deceleration burn:

[math]t_0 = (-e^{\frac{-v_{initial}\dot m}{F_{thrust}}}+1)\frac{m_{initial}}{\dot m}[/math]

So this would be the upper limit for the outer integral...
Calculating the integral of v(t) using the tool above then leads to

[math]x = \frac{F_{thrust}(m_{initial}-\dot mt_0)log{(\frac{m_{initial}}{m_{initial}-\dot mt_0})}}{\dot m^2}-\frac{F_{thrust}t_0}{\dot m}+v_{initial}t_0[/math]

So this should do the trick.. :)
 
Last edited:
Here are some more complex algorithms for landing algorithms similar to what is being discussed with some example code and online references to a technical paper and a thesis.

If you assume that the gravity acceleration is constant and no aerodynamics, then you can write an analytic expression for the final state after a finite duration burn where the direction of thrust is linear in time. Either constant thrust or constant acceleration segments can be used with the same algorithm through some trickery. Basically, it is a really quick way to get a good estimate of the final state after a finite burn. It turns out that the "direction of thrust is linear in time" constraint is close enough to the optimal profile to be useful for real work.

You can do the burn in (for example) 4 segments holding the gravity acceleration constant (and different) in each of the 4 segments, probably based on the estimated state in the middle of the segment. Or 10 pieces, or whatever you decide is necessary. It isn't usually necessary for guidance purposes to use too many, because the model becomes more accurate as you approach burnout.

This kind of algorithm is sometimes called a "Thrust Integral".

Once you have a Thrust Integral model, you can use it by solving a non-linear programming problem with 6 control variables (ignition time, two starting angles, two final angles and the burn time) and 6 constraints (desired position vector and velocity vector at cutoff).

The equations can look something like this:
Code:
//
// Name:       _calcThrustIntegrals
// Class:      GuidanceStrategy
// Namespace:  MvjFlight
//
// Purpose:    Reduced order method (analytic approximation, 
//          assuming constant thrust and average gravity)
//          Ref: Dukeman Thesis, p.33..35
//
// Parameters: see below
//
// Exceptions: None
//
// Return: none
//
void
GuidanceStrategy::_calcThrustIntegrals(
   MvjOrbiter::StateVector &svIn,   // input state vector, starting state
   MvjMath::Vector3     &Avec,   // pointing direction rate vector
   MvjMath::Vector3     &Bvec,   // initial pointing direction
   double t,   // s, burn time
   double m0,  // kg, initial mass
   double c,   // m/s, exit vel
   double T,   // N, thrust
   MvjOrbiter::StateVector &svOut) // output final state estimate
{
   //
   // state input
   // 
   Vector3 rVec = svIn.getPosition();
   Vector3 vVec = svIn.getVelocity();
   // do separately, since will need Rmag^3 later
   double Rmag2 = rVec.sqrLength();
   double Rmag = dSqrt(Rmag2);
 
   //
   // solution vec
   //
   double A = Avec.length();
   double B = Bvec.length();
   double A2 = A*A;
   double B2 = B*B;
   BASE_ASSERT(A > 0.0);
   BASE_ASSERT(c > 0.0);
   if (!(A > 0.0 && c > 0.0)) {
      svOut = svIn;
      return;
   }
   // Vehicle Model
   double mDot = T / c; // kg/s
/* // (need to do this on the input side)
   bool accLimEna = false; // NOTE: this formulation has not yet been tested
   if (accLimEna) {
      // Overwrite mass flow rate to impose acceleration constraint 
      // using the same equations for non-constrained trajectory
      // REF: Ref: Dukeman Thesis, p.35
      mDot = 0.001 * m0 / t;
      // NOTE: Input such that: T / m0 = accel limit,  is probably required
   }
*/
   //
   // Thrust Integral factors
   // 
 
   Vector3 vecD = Avec * m0 + Bvec * mDot;
   double d = dSqrt(vecD.dot(vecD));
   double ATB = Avec.dot(Bvec);
   double e = ATB + A*B;
   Vector3 At_Plus_B = Avec * t + Bvec;
   double f = At_Plus_B.length(); // dSqrt(At_Plus_B.dot(At_Plus_B));
   double g = ATB + A2*t + A*f;
   double BBMdot = B2*mDot;
   double p = m0*(BBMdot + A2*m0*t+ATB*(m0+mDot*t)+d*f);
   double mT = m0 - mDot * t;
   double q = mT*(d*B + m0*ATB + BBMdot);
   double tau = m0/mDot;
   double Ainverse = 1.0/A;
   double logEG = dLog(e/g);
   double logPQ = dLog(p/q);
   double f11 = (T/mDot) * ( 
      (f - B)/A2 
      + logEG*(t - tau + ATB/A2)*Ainverse
      + logPQ*m0*(t-tau)/d
      );
   double ca = (T/mDot)*(Ainverse*logEG + (m0/d)*logPQ);
   double cb = (T/d)*logPQ;
   Vector3 dVt = Avec * ca + Bvec * cb; // Thrust Integral delta velocity
// ca = f11 * T; // (??? This is an apparent typo in Dukeman's thesis: Remove redundant *T)
      ca = f11; // ??? too many Thrusts? do units analyis
   cb = T*( (-Ainverse/mDot) * logEG - (mT/d/mDot)*logPQ );
   Vector3 dRt = Avec * ca + Bvec * cb;   // Thrust Integral delta position
   //
   // Calculate predicted position (constant gravity per initial position)
   //
   double t2o2 = t*t*0.5;
   double Rmag3= Rmag*Rmag2;
   Vector3 Rp0g= rVec + vVec*t; // coast portion
   Rp0g += dRt; // coast portion + thrust portion (still without gravity yet)
   Vector3 gVecR0= rVec * (- _gb.mu() / Rmag3); // starting position gravity
 
   // predicted position Rp with effect of starting constant gravity acceleration 
   Vector3 RpVec = Rp0g + gVecR0 * t2o2; 
   //
   // Calculate average gravity (average of starting and predicted positions)
   //
   double  RpMag2= RpVec.sqrLength();
   double  RpMag = dSqrt(RpMag2);
   double  RpMag3= RpMag*RpMag2;
   Vector3 gVecRp= RpVec * (- _gb.mu() / RpMag3);
   Vector3 gVecAv = (gVecR0 + gVecRp) * 0.5;
   //
   // Calculate final state estimate using average gravity
   //
   Vector3 rVecOut = Rp0g + gVecAv * t2o2;
   Vector3 vVecOut = vVec + dVt + gVecAv * t;
   svOut = StateVector(TimeTag(svIn.getTimeTag().getTimeSec() + t,0.0), rVecOut, vVecOut);
}
//
// Name:       _calcThrustIntegralsN
// Class:      GuidanceStrategy
// Namespace:  MvjFlight
//
// Purpose:    Reduced order method (analytic approximation, 
//          assuming constant thrust and average gravity)
//          Ref: Dukeman Thesis, p.47..50
//
// Parameters: see below
//
// Exceptions: None
//
// Return: none
//
void
GuidanceStrategy::_calcThrustIntegralsN(
   int      n, // number of pieces to break propagation time t into
   MvjOrbiter::StateVector &svIn,   // input state vector, starting state
   MvjMath::Vector3     &Avec,   // pointing direction rate vector
   MvjMath::Vector3     &Bvec,   // initial pointing direction
   double t,   // s, burn time
   double m0,  // kg, initial mass
   double c,   // m/s, exit vel
   double T,   // N, thrust
   MvjOrbiter::StateVector &svOut) // output final state estimate
{
   svOut = svIn;
   double tn = t / (double)n;
   double te; // time elapsed to start of step
   double m0n = m0;
   double mDot = T/c;
   Vector3 BvecN = Bvec;
   for (int i=0;i<n;i++) {
      _calcThrustIntegrals(svOut,Avec,BvecN,tn,m0n,c,T,svOut);
      te = tn *(double)(i+1);
      BvecN = Avec * te + Bvec;
      // set up for next step
      m0n = m0 - mDot * te;
   }
}

See: http://etd.gatech.edu/theses/available/etd-01032005-164555/
"Closed-Loop Nominal and Abort Atmospheric Ascent Guidance for Rocket-Powered Launch Vehicles," Greg A Dukeman, 2004.

Or use an algorithm specialized for vacuum planetary landings. I like:
"An Optimal Guidance Law for Planetary Landing," Cristopher N. D'Souza, Charles Stark Draper Lab, 1997
http://www.draper.com/digest98/paper9.pdf
This is an optimal calculus of variations based algorithm assuming constant gravity (low altitude) and no rotation of the coordinate systems (particularly good for Earth's moon).
The guts of this algorithm look like: (see below)
Here, _tgo has been calculated using ::_calcTgo and this value is used in ::getPointingDirection. The RA (range coordinates) frame is as described in the paper: has X along azimuth and Z up. e.g.: N,W,Up for azi = 0. See the D'Souza paper.
Note that the "getPointing Direction" function is somewhat misnamed. In this case, it is more properly the commanded thrust acceleration vector. I happened to fit this newer algorithm into an existing framework for testing various guidance algorithms. The others calculate the pointing direction and thrust separately. This one calculates them together, so it doesn't yet fit exactly into the existing framework at this point (the framework has to expand).
I have used this to guid a DG on approach to Brighton Beach using main engine and TVC based attitude control. I'm currently at the point of doing the flip over to hover engines as it reaches a spot over the landing site and then the vertical final touchdown. For that, I need to transition to a different attitude controller (RCS) and haven't done the logic for the transition yet. For an all vertical lander like the Lunar Module, you wouldn't have that extra work.
Code:
//
// Name:       _calcTgo
// Class:      GuidanceStrategy_PoweredLanding
// Namespace:  MvjFlight
//
// Purpose:    D'Souza analytic algorithm for optimum time-to-go calculation
//
// Parameters:  None
//
// Exceptions: None
//
// Return:  optimal time-to-go solution
//
// 
double 
GuidanceStrategy_PoweredLanding::_calcTgo(void)
{
   double output = 0.0;
   //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   // convert sv into Ra frame
   //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
      // ***NYI***
   //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   // Calculate Tgo
   //=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   double v_dot_r = _svNav.getVelocity().dot(_svNav.getPosition());
   double v_dot_v = Vector3::sqrLength(_svNav.getVelocity());
   double r_dot_r = Vector3::sqrLength(_svNav.getPosition());
   // solve reduced fidelity (flat planet) 
   // powered landing problem for optimal time-to-go
   // per I-Load _gamma selection
 
   MVJ_ASSERT(_gamma >= 0.0);
   double g = _gb.surfaceGravityAcceleration(); // m/s^2 equatorial surface
   double a,b,c, denom;
   denom = _gamma + g*g*0.5;
 
   // t^4 + a* t^2 + b* t + c = 0
   a=  -2.0 * v_dot_v / denom;
   b= -12.0 * v_dot_r / denom;
   c= -18.0 * r_dot_r / denom;
 
   double a2, a2m4c;
   a2 = a*a;
   a2m4c = a2 - 4.0 * c;
 
   double alpha, beta, delta, Z;
   alpha = a2m4c - 4.0*a2 / 3.0;
   beta  = (16.0*a2*a - 18.0*a*a2m4c)/27.0 -b*b;
   delta = alpha*alpha*alpha/27.0 + beta*beta/4.0;
 
   // (future sqrts)
   MVJ_ASSERT(alpha >= 0.0);
   MVJ_ASSERT(delta >= 0.0);
   double deltah, halfbeta;
   deltah= dSqrt(delta);
   halfbeta = 0.5*beta;
      // cube root = pow ( abs ( val ), 1.0 / 3.0 )
   Z = dCubeRoot(-halfbeta+deltah) + dCubeRoot(-halfbeta-deltah);
 
   double eta;
   // invert eq.58
   eta = Z - 2.0*a/3.0;
   MVJ_ASSERT(eta >= 0.0); // future sqrt
   // will be taking sqrt later, eta must be positive
   if (eta > 0.0) {
      double zeta, xi;
      // MVJ: remove the minus sign from this zeta: 
      // It screws up the sign matching required to get the signs
      // correct for the 4 solutions
      //      zeta = -0.5*b / eta;
      zeta = 0.5*b / eta;
      xi = 0.5*(a + eta);
      // It appears from the requirement for at least 1 real root, that 
      // equation (75) has an error: the second sign of the right hand radical
      // should match that of the left hand radical (after the zeta correction above). 
      // They certainly can NOT be the same at least, otherwise 
      // the radicals are the same and any negative
      // radical would lead to 4 imaginary solutions.
      // (Since we have to have at least 1 real soln, 2 must be real therefor
      // can only have at most 2 imaginary solutions.
      // per: (eq. 8') [URL]http://en.wikipedia.org/wiki/Quartic_equation#Special_cases[/URL] 
      // the rad >= 0 is required for a real root, so only consider those
      double etah = dSqrt(eta);
      double radp = eta - 4.0*(xi + etah*zeta);
      double radn = eta - 4.0*(xi - etah*zeta);
      double radh;
      // store the up to 4 solutions into this array
      double tgo[4]= {-1.0, -1.0, -1.0, -1.0};
      unsigned int numRealSolns = 0;
      if (radp >= 0.0) {
         radh = dSqrt(radp);
         // future optimization could include the 0.5* in the etah, radh factors
         tgo[numRealSolns++] = 0.5*(+etah + radh);
         tgo[numRealSolns++] = 0.5*(+etah - radh);
      }
      if (radn >= 0.0) {
         radh = dSqrt(radn);
         // future optimization could include the 0.5* in the etah, radh factors
         tgo[numRealSolns++] = 0.5*(-etah + radh);
         tgo[numRealSolns++] = 0.5*(-etah - radh);
      }
      // choose best tgo. (smallest positive)
      output = 99999.0;
      for (unsigned int i=0;i<numRealSolns;i++) {
         if (tgo[i] > 0.0 && tgo[i] < output) {
            output = tgo[i];
         }
      }
      // for v_dot_r > 0 (v pointing away from target), only 1 real positive root.
         printf("tgo solns = %7.2f %7.2f %7.2f %7.2f\n",tgo[0],tgo[1],tgo[2],tgo[3]);
         output = output;// break point
#if 0// compute residual of polynomial to indicate any errors
      {
         // t^4 + a* t^2 + b* t + c = 0
         double res = c+ output*(b + output*(a+ output*output));
         printf("residual best soln (%g) = %g\n",output, res);
         res=res;// breakpoint
      }
#endif
#if 0 // compute the Jmin performance index = estimate integral[ a^2 dt ]
      {
         double Jmin = (_gamma + 0.5*g*g)*output
            + _svNav.getVelocityZ()*(-g) + 2.0*v_dot_v/output  // v_dot_g
            + (6.0/output/output) * (v_dot_r + (6.0/output)*r_dot_r);
         Jmin /= (0.3048*0.3048);
         Jmin = Jmin; // debug break
 
      }
#endif
   } else {
         output = output;// break point
         MVJ_ASSERT(0);
   }
   return output;
}
 
// Ra-frame thrust acceleration vector
//
MvjMath::Vector3 
GuidanceCommand_PoweredLanding::getPointingDirection( // NON-unit vector of thrust accel in Ra-Frame
           double                  time,  // sec, input time, relative to same reference as t0
           const MvjMath::Vector3  &pos,  // m, current position vector, Ra-frame (Range frame)
           const MvjMath::Vector3  &vel,  // m/s, current velocity vector, Ra-Frame (Range frame)
           double                  surfaceGrav // m/s^2
           )
{
   // time-to-go is reduced as time moves on from _t0
   double grav = surfaceGrav; // m/s^2
   double tgo = _tgo - (time - _t0);
   if (tgo < _minimumTimeToGo) {
      // return vertical accel for time-to-go below the threshold
      return MvjMath::Vector3(0.0,0.0,grav);
   } else {
      double tgo_inv = 1.0/tgo;
      MvjMath::Vector3 output = vel *(-4.0*tgo_inv) + pos * (-6.0*tgo_inv*tgo_inv);
      output.z += grav;
      return output;
   }
}

Hopefully these constant gravity vacuum algorithms will show that useful analytic solutions are possible and roughly how complicated they are. If anyone cares to recreate the algorithms from the papers, this code can serve as a reference implementation.
 
Last edited:
I'm new in the community, but from what i've seen from posts here and in the hangar... the original author is not "among" us anymore...? (Or did i just ask another stupid -and macabre- question?)

Sadly, that is correct. "LazyD" passed away before completing LOLA MFD.

His Land MFD was completed and worked fine in Orbiter 2005, but gets mixed results in O-06, depending on which vessel you're flying.

---------- Post added at 12:17 AM ---------- Previous post was at 12:14 AM ----------

mjessick, I love reading your posts. I can't understand it all, but it's nice to be in the company of people who know what they're talking about, which is always a good thing on the interwebs!

When it comes to stuff like this I have to sit down and work it out for myself, I can't figure stuff out from reading pages of code or equations. At least I know where to go for hints when I get stuck.
 
Back
Top