AGS Lunar Orbit Insertion - Apollo 11

[Thespacer]

Hi all

Just curious if anyone has tried an AGS-guided orbit insertion, using the stock Apollo 11 scenario, just before lunar liftoff (no. 17)? I find it consistently launches into a ~77k foot insertion altitude, despite the target altitude (232) being 60k feet. I’ve followed the AGS procedures in the LM G&N Dictionary and also the FP6 manual, as far as I can tell.

Curious if this is an anomaly, an AGS procedures/initialisation issue, expected behaviour, or my error.

 

[rcflyinghokie]

I know the AGS works just fine for insertion, I will jump into that scn and check its configuration and such and compare to a fresh powerup and report back here.

 

[indy91]

Ah this is a fun one!

Due to an unfortunate series of events involving a bug that got fixed a year ago, this older mission scenario and a change in behavior of the ascent stage, the AGS has a wrong pitch cant angle for the APS loaded.

Basically, the APS engine is canted by 1.5° in pitch to better point through the center of gravity of the LM, as it can't be gimballed. The AGS needs to know this number to properly point its thrust direction to where it needs to be. But in this older scenario it has a cant angle of 5° loaded. During ascent this is basically pointing the LM too far upwards by 3.5° (5°-1.5°) all the time. And that causes the altitude overshoot.

In that "before lunar liftoff" scenario, you need to load this into the DEDA:

566+01531 (pitch cant angle)
602+00000 (roll cant angle)

Then it should work fine. And I will go through all our mission scenarios to find instances where the wrong values are loaded. In new missions this can't happen anymore, as the bug that caused this wrong value has long been fixed.

 

[Thespacer]

Indy, Rcflyinghokie,

Thanks again for your assistance. I’ve fallen into the AGS rabbit hole and have nearly completed an AGS-only rendezvous for Apollo 11. The sticking point at the moment is just after the CDH burn, while doing TPI search and execute. Those calculations seems to go fine and the predicted TPI Tig (after monitoring R303) is a few mins earlier than the nominal PAD value, which seems more or less nominal.

But when I reach the point of calculating the external delta V (450, 451 and 452), the DVX value R450 is +60000, which seems to me like an error code as opposed to a value of any actual meaning. The CSI and CDH calculated R450 values were all reasonable.

The FP6 manual does not shed any light for me on this.

Curious if anyone knows what that might mean. I notice I also get R450+60000 during the TPI phase when I did my last PGNS rendezvous, and was just playing with the AGS as a backup. User error?

Not at my computer till the weekend, if a scn might be of use here.

 

[rcflyinghokie]

Check DEDA 371, if its the same as your 450 value then you have not converged on a valid solution. (FP6 manual 25-5)

Also, you shouldn't be using/modifying 450-452 for any of the rendezvous burns targeted in AGS, those are only for inputting external values such as those generated by the PGNS or MCCH. (FP6 manual 27-2)

 

[Thespacer]

Thanks! Will look closely again at the references. I wasn’t modifying 450-452, just reading the values so I knew what values to put in N81 for P76. So much at least seemed to me consistent with the procedure in the G&N Dictionary (at page AGS 9). But I confess I am cross-pollinating procedures to fill any gaps in my knowledge of the process (mainly those in the Mission G rendezvous manual, which do seem to suggest one would be loading targets into 450-2)

 

[rcflyinghokie]

Ah I see what you are saying. That is interesting as it has you load them there but says not to in the FP6 manual. It could be an order of operations thing or loading CSM or MCC values since you are computing a burn update. In any case that shouldn't impact what you were doing. The root of your issue is you not having a solution converge.

 

[Thespacer]

Just to provide some closure on this thread…

RV was successful, and everything was fairly nominal (e.g., 371 was 58fps, so that had definitely converged well).

So while I was not able to get 450 to converge, I had another look at the various procedures out there, and I think the FP6 manual and the G&N dictionary were better to follow (rather than the Mission G Rendezvous procedures), as neither of them referred to even reading 450 during TPI.

I abandoned the idea of updating the CSM’s knowledge of the LM’s SV after the TPI burn. I’m not sure if a real-life AGS abort would have meant the CSM following its usual P76 processes anyway?

All that aside, AGS seems to be a quite robust system. While the manual radar updates were a bit tedious, the whole insertion/RV process via the AGS was pretty straightforward, and not that much worse than PGNS in terms of workload. Sufficiently accurate too. I gather with FP8 or later that the automatic incorporation of radar updates made it even more user friendly.

 

[rcflyinghokie]

Just to provide some closure on this thread…

RV was successful, and everything was fairly nominal (e.g., 371 was 58fps, so that had definitely converged well).

So while I was not able to get 450 to converge, I had another look at the various procedures out there, and I think the FP6 manual and the G&N dictionary were better to follow (rather than the Mission G Rendezvous procedures), as neither of them referred to even reading 450 during TPI.

I abandoned the idea of updating the CSM’s knowledge of the LM’s SV after the TPI burn. I’m not sure if a real-life AGS abort would have meant the CSM following its usual P76 processes anyway?

All that aside, AGS seems to be a quite robust system. While the manual radar updates were a bit tedious, the whole insertion/RV process via the AGS was pretty straightforward, and not that much worse than PGNS in terms of workload. Sufficiently accurate too. I gather with FP8 or later that the automatic incorporation of radar updates made it even more user friendly.

Good to hear! I need to investigate that a bit more. And its not that "450" didnt converge, but it pulls a DVX value from your TPI targeting if I am not mistaken, so if 371 was +60000 then that got transferred to to your dV values as well.

Also I was reading the FP6 manual again, I am assuming (load solution to be executed) in the rendezvous procedure just means if you had a bad TPI calculation (ie not converged) you would load there the CSM or MCCH solution. So that is in keeping with other procedures where you dont touch those values unless loading an externally calculated solution.