Advanced Question Moments of inertia of two docked vessels

[indy91]

This question is specifically for NASSP, but might apply to Orbiter in general.

I am in the process of analysing the behavior of the Digital Autopilot (DAP) of the Lunar Guidance Computer (LGC) during a docked burn on the Descent Propulsion System (DPS). Since we started being able to perform burns with the DPS in NASSP, controlled by the DAP of the emulated LGC, we have noticed that it is never stable while the CSM and LM are docked. Of course there are many possible causes and we probably will need to implement variable center of gravity and principal moments of inertia for overall better behavior.

But something about the moments of inertia of our CSM and LM is way off. At this point I am not sure if this isn't a bug in Orbiter. From this presentation one can derive how Orbiter calculates the moments of inertia for docked vehicles. From documentation about the LGC I can also derive the calculations it does to get the current moments of inertia of the CSM+LM. I understand that Orbiter does this in a simplified way, but the discrepancy is pretty significant:

The general parameters used in this graph are:

LM PMI: (2.5428 2.2871 2.7566)
CSM PMI: (4.3972 4.6879 1.6220)
CSM mass: 15472 kg
CSM to LM CoG-to-CoG: 6.2 meters

Now, the mass normalized PMI will only be so accurate for the full range of masses and center of gravity in real spacecraft shift. But these values for the separate CSM and LM are not far off from what the DAP expects. I have some more graphs for that, but I didn't want to fill a whole page.


If I calculate mass normalized moments of inertia around the Y or Z axis (Apollo coordinates, fairly symmetrical around the X-axis) then I get roughly these numbers:

Apollo 15 CSM+LM from the CSM Operational Data Book, heavy LM, mid-mission CSM: 17.0
DAP of the LGC for a heavy LM and mid-weight CSM: 14.4
Orbiter: 61.1

I put all the calculations that Orbiter does in a MATLAB script to calculate the numbers that Orbiter would be using. I haven't found an easy way to get the moments of inertia from the Orbiter API to verify my calculations, so I was using angular momentum divided by angular acceleration, all during thruster firing in one axis.

One interesting effect I noticed during testing is that you can turn down the PMI defined for both vessels to almost 0, their contribution isn't very large anyway. Most of the moments of inertia is caused by the distance between the centers of gravity of the two vessels. The border case of this is 6 point masses concentrated very close to the CoG of both vessels. But the resulting moments of inertia are still way too high.

I guess in conclusion I have 3 questions:

1. Is there something obvious I am missing (wrong values for anything I listed above) in how the we should set up our docked CSM+LM to get accurate moments of inertia?
2. Is there some trickery we can do with Orbiter to get accurate values for CSM+LM so that docked burns controlled by the Virtual AGC are working better?
3. Assuming for a moment that Orbiter is at fault, does it simply come down to Orbiter calculating the moments of inertia in a very inaccurate way, or is there maybe even a bug in the calculations that Orbiter does?

 

[martins]

I've had a look at that presentation (page 8) and it strikes me that there may be a mistake: when constructing the PMI values of the shifted samples (J'), the mass (m) should represent the mass of the individual samples, which is 1/6 of the total vessel mass (since each vessel is represented by 6 point samples). It is quite possible that I didn't take that factor 1/6 into account. At least it's not obvious from the slide.

I haven't got the Orbiter sources to hand right now, but I'll check tonight. In any case, if the PMI values that Orbiter reports for the docked CSM+LM assembly were divided by 6, would that fit with your predictions?

 

[indy91]

I'm not entirely sure. If I calculate the moments of inertia this way, then I get these PMI for the combined CSM+LM:

10.18304 10.18519 0.36647

So six times smaller than before. The x and y values look much more accurate and actually very close to a two mass points approximation of the CSM+LM. But the z value is too small. 6x too small. I get the feeling that the problem with the calculation is caused by moment arms due to the distance between the CoGs of the two vehicles rather than the masses of the 6 point masses per vehicle. But right now I don't have any fancy equation to contribute that solves the issue.

 

[martins]

Working on this a bit more, it looks like the computation of the samples themselves is wrong, because they can't be computed from the mass-normalised PMI values.

I've modified my equations a bit, and now I get (for CSM mass = 15472 kg and LM mass = 10000 kg) the following PMI values for the docked assembly:

PMI = [12.8357, 12.9119, 2.0674]

Does this look plausible?

I'll try to write up a new Technote with details as a basis for discussion (might take me a few days).

I'll also try to put up a new beta for testing, but unfortunately I am in the middle of refactoring my build process, and this needs to be done before I can do anything else. This will be at least another week.

 

[indy91]

Those numbers look much more plausible and the TVC DAP of the LGC should have no issues controlling the docked CSM+LM with those moments of inertia. Thanks so much for looking into this issue! I am looking forward to trying the new behavior once the next Orbiter Beta is ready!

I wonder what consequences this change has for other addons. It's also surprising to me that this hasn't really been noticed before. The only reason I noticed it was because from documents about the DAP we can clearly derive what moments of inertia the LGC expects. I guess there just aren't many projects for Orbiter that perform burns with docked vehicles.

Knowing now that the moments of inertia in Orbiter are 5x higher than what the AGC expected just makes it more impressive that the Command Module Computer was able to handle it. The CMC uses a pretty complex digital filter for docked burns and also has the advantage of a much faster gimballing engine (SPS can move at about 2°/s, the DPS only at 0.2°/s). And docked burns controlled from the CSM have been working pretty well in the past. The LGC simply needs a very accurate knowledge of the moments of inertia to be able to control docked DPS burns. Now Apollo 13 will be able to come home in NASSP, haha.

 

[martins]

Here is the promised technote. I'd be quite grateful if you could review it. Let me know any mistakes or anything unclear or missing.

Cheers!

Edit: oops, already spotted an error in Eq. 12 ...

 

[indy91]

Here is the promised technote. I'd be quite grateful if you could review it. Let me know any mistakes or anything unclear or missing.

Cheers!

Edit: oops, already spotted an error in Eq. 12 ...

Thanks!

I also spotted that error, caused me some trouble for a few minutes. Just the sqrt(6) being in the wrong place. Other than that the document looks pretty clear and accurate.

I put all these new calculations in my script, here the results:

CSM mass, 15472 kg, static center of gravity for both CSM and LM:

CSM mass 15472 kg, variable center of gravity for the LM:

My favourite one. CSM mass 30000 kg, variable center of gravity for the LM:

A variable center of gravity for the LM is a potential feature that might be included in NASSP. Simple reason being that the CoG moves quite a bit in the LM while burning propellant. But I think even without that the new behavior in Orbiter will lead to good results using the DPS for docked burns. I am not too troubled about the graph with a mid-weight CSM. Looking forward to verifying the calculations of my script in the Orbiter Beta.