## Robust test for apogee

Dynamics and environment models, spacecraft model, solver algorithms, etc.

### Robust test for apogee

In another post, I mentioned that I was having trouble with a lunar mission, because the TLI burn produces a highly elliptical orbit that is very close to becoming parabolic or hyperbolic. Of course, the apocenter is undefined for these orbits. I've seen the DC solver choke if its trial values happens to hit on this case.

I'd like to suggest a solution: Instead of computing an apocenter, compute its reciprocal. As the orbit's eccentricity grows, this reciprocal approaches zero, passes through zero for the parabola, and goes negative for hyperbolas. If you add this reciprocal to the orbit properties, the DC solver can search for the solution with no problems. I use this technique in a Simulink model, and it works just fine.

The approach also works when searching for the SMA.

Just a suggestion,

Jack
JackCrenshaw

Posts: 18
Joined: Thu Aug 15, 2013 12:00 pm

### Re: Robust test for apogee

Hi Jack,

Do you mean the radius of apoapsis here, and if so, that means target on 1/RadApo? You could script this immediately if this is what you are talking about by creating a user Variable and targeting on the user variable value

Steve
shughes

Posts: 443
Joined: Mon Jun 09, 2008 6:27 pm

### Re: Robust test for apogee

Well, yeah, that's sort of what I mean, but I'm not sure that just taking the reciprocal of the computed apogee will do the trick. As you know, as the eccentricity of the orbit goes >= 1, the apogee ceases to exist.

Same-o with SMA. At the boundary, it goes from a huge positive number, through infinity, to a huge negative number.

I had a Simulink model for generating finite-thrust maneuvers. It was supposed to stop on reaching the desired apogee -- and it did. But because the ECC was close to 1, when I called the model from MATHCAD's fzero or fminsearch functions, they would sometimes give trial values that violated the ECC < 1 constraint.

So I reformulated the thing to calculate 1/apogee, and that fixed the problem.

You can't just compute 1/apo by inverting it; you have to compute it directly from R and V.

In retrospect, it was presumptuous of me to offer the algo. It's not exactly rocket science (well, Ok, maybe it is), and the computations are very simple. Still, it's there if you want it.

Jack
JackCrenshaw

Posts: 18
Joined: Thu Aug 15, 2013 12:00 pm