OK, here's where I'm at. As always, anyone who wants to jump in and offer comments, suggestions, etc. is welcome to do so.
I ran a test flight to look at several things: (1) Sextant MFD (zip of beta test stuff is attached); (2) try the method in lunar orbit to make sure I wasn't accidentally incorporating some Earth-specific factor into the general method; and (3) to try to get a handle on some problems with the out-of-plane corrections.
As of now, it looks to me like the in-plane correction method is basically correct, although it might benefit from some tweaking. There seems to be a tendency to overcorrect at times, but I might be able to introduce factors into the equations to correct for this. That would be transparent to the user; instead of computing <parameter> = C1 * tgt_radius + C2 * delta-H + B1, he or she would compute <parameter> = C3 * tgt_radius + C4 * delta-H + B2. The tables would just have different numbers, in other words.
There are three axes of motion in play for the active craft; motion in-plane, motion out-of-plane; and the third dimension which would correspond to a delta-vee directly at or away from the target craft. Of course, those don't line up with the prograde, normal, and radial vectors of the active craft's orbital motion. I was hoping that might work to my advantage, and that in correcting for the target craft's in-plane apparent motion the active craft would also regulate its own prograde motion (or at least a workable combination of prograde and radial motion), and that in doing so the third dimension would more or less take care of itself. Unfortunately, that doesn't seem to be happening. With very tightly defined pilot error terms (basically simulating what might be expected if it were Neil Armstrong flying the rendezvous), the method fails about 3% of the time, which indicates the error rate would be larger if any of us mere mortals were to try it. The most common failure is that the rendezvous runs out of time, and the most common reason seems to be that the prograde velocity is eaten away by the MCCs. In that situation, the active craft ends up on a target-relative straight-line trajectory in toward the target, but at say 4 km range and closing at 1 m/s (in LEO, normal time for the entire rendezvous trajectory is ~1900 seconds) ... or worse, on a target-relative straight-line trajectory backing
away from the target at a few m/s. So I'm gonna have to put something in to check and maintain the active craft's target-relative forward motion. One of the things I tried in the test flight was adding in to the MCC this procedure: if range rate toward the target is less than the predicted value, do a burn toward the target to make up the difference. That seemed to work, at least in the few tries I did it.
The off-plane corrections present a special problem. For an example of that, eyeball the attached image "oop_prob." Ignore the plus signs and consider this situation. The active craft is in the green orbit, directly over the equator, and the target craft is somewhat above it in the yellow orbit. They're at the blue dots toward the left of the image. Both are moving from west to east, and relative inclination is exaggerated to make the example more clear. From the active craft's perspective (pitched up to target from wings level with horizon), the target will appear to be moving to the right. This would happen even if the craft were at the same radii, but the fact that the active craft is lower and so has a higher velocity exaggerates this apparent motion even further. However, the rendezvous should occur 130 degrees later, at the red dot over Panama, and the proper trajectory for the active craft to get there is the blue arc, which requires a
leftward delta-vee.
I think the basic method of doing off-plane corrections the same way as in-plane corrections still works in the braking phase, when the pilot is merely trying to maintain zero apparent motion. However, that simply means burning toward the target's motion if it moves, and no special attention to in-plane vs out-of-plane motion is necessary at that point. For any MCCs to span a longer distance, though, I think a different method is necessary.
I tried a method Aldrin described in his dissertation (pages 94-99), and that worked quite well using only numbers from Orbit MFD and Sextant MFD. Because of significant figure limitations it doesn't work perfectly, but it's good enough even with that data that two or three MCCs (each successively fine-tuning) do the trick. The computations would be too involved for an Orbinaut to do in real time while doing the rendezvous, but I'm hoping that can be simplified somewhat. The general rationale in what I'm trying to put together isn't to make the approach to the braking phase perfect, it's merely to make that approach good enough so that the error to be cleaned up in the final braking phase is reasonable. Between that and the fact that the coelliptic configuration makes certain things very predictable, I'm hoping this scheme can be simplified by strategically placing the out-of-plane MCCs so that the computations might simplify to a reasonable workload, or maybe even looking up some numbers in tables or plots of delta-h vs target, etc. At the same time I'll try to do away with checking Orbit MFD's numbers and work it all back around to the pilot's assumed target radius, delta-h, etc.
So at this point it's starting to look like there will be three distinct styles of MCCs; one based on in-plane apparent motion, one based on other measurements to establish the out-of-plane correction, and one along a straight line to the target craft. That will be more complex than the tutorial example, but hopefully I can get it to where it's not overwhelming for a real-time rendezvous. If it's any consolation, that should make the procedure a little more realistic in how it "felt" to do this for real -- not "felt" in an Oprah-ish kind of way, but rather saying that the real procedure did involve looking up values on polar plots, etc.
I've just bought a new 1 TB drive for my PC and have added Solaris x86/x64 to it. The difference between that and 32-bit XP is flabbergasting. For example, the "program C" I mentioned earlier in the thread does 2.89 million cases per minute in Solaris x64 as compared to 1.56 Mcases/min under a DOS shell in XP on the same PC. Since some of these programs take quite a while to run, I'm going to port the code over to Solaris. Shouldn't be much work, since everything's in straight C. Anyway, that's what I'll be working on for the next day or two. I'm also itching to put aside the math for a few moments at some point and get back into the cockpit.
SAM
