Coelliptic Gemini/Apollo rendezvous

[Sam]

Alright, you guys win. :lol: To my mind, if one knowledgeable person says he or she would prefer something differently, I'm prepared to write it off as a personal idiosyncracy; when two voices say the same thing, then it starts getting different. The next version will give figures like "4.4 degrees/2 mins" or something similar.

Thanks again for the time you've both taken to look at this and to offer your comments. The disadvantage I've got is that I already knew how to do what I was attempting to describe before I wrote it, so my viewpoint can get myopic and "fresh eyes" are a great help on this.

> The range and range rate should look reasonable. I know 3 more things. [...] the range rate will decrease over time, so my arrival time is not a linear function of range.

That one I can give an answer to right now, it's one of the things I looked at when preparing this. Given reasonable LEO orbits and with the 26 degree and 130 degree parameters held constant, the transfer time will always be about the same.

Suppose the active, chaser craft is held at a constant altitude, the 26 degree initial elevation and 130 degree transfer angle are preserved, and the delta-H is varied. Well, in order for the target to be at 26 degrees elevation, it's gotta be somewhat in front of the chaser, so the phase angle (TrL difference) at the terminal phase initiation (TPI) burn increases as delta-H increases. For example, if the active craft is at 6637 km radius (as in the tutorial's SCN), delta-Hs of 10 km, 24 km, and 50 km mean phase angles of 0.18, 0.42, and 0.87 degrees respectively, and since the active craft travels 130 degrees during the rendezvous, this means that for those delta-Hs the target must travel 129.82, 129.58, and 129.13 degrees respectively.

Now, consider this. With those constraints (active craft radius, initial elevation, active craft's transfer angle) imposed, the larger the delta-H, the higher the target which means a longer orbital period, but a larger delta-H also means that the target travels a shorter portion of its orbit. Guess what? Given reasonably small delta-Hs, those two things nearly cancel out. With the active craft's radius = 6637 km, a delta-H of 1 km means a transfer time of 1943 seconds, whereas a delta-H of 300 km means a transfer time of 2001 seconds, only one minute more. (The numbers are for the "raw" trajectory, with no braking at the end.) That difference increases if you vary the active craft's radius, but not much. For example, with the active craft's radius at 20,000 km, the difference between transfer times for delta-Hs = 1 km and 300 km is only about 90 seconds.

While varying the delta-H doesn't have much of an impact on transfer time, varying the active craft's radius while staying in LEO does increase the transfer time, but not dramatically. With delta-H = 24 km, the transfer time is 2109 seconds with the active craft at 7000 km, versus 1943 seconds with the active craft at 6637 km, 164 seconds difference.

So at any reasonable LEO radius and delta-H, the raw trajectory's transfer time will be a half hour plus some spare change. The braking phase and subsequent docking add time, but that's seems more or less constant. I haven't clocked how long it takes to get from TPI to braking phase, but every time I've run this the time from TPI to docking has been about 48-50 minutes.

> I agree with Chuck that the useful number in the chart is 4.4 degrees of drift against a killrot in two minutes @ 37 km range.

In the tutorial I said that I picked 37 km because Aldrin said that the Gemini-era technology imposed that limit, but I also said that I had tried starting MCCs at greater ranges and hadn't seen any dramatic differences. What I didn't say was that I haven't seen any differences. (The actual technique Aldrin was discussing was somewhat different from this technique.) I haven't done enough trials and other work to make anything like a definitive statement, which is why I didn't say that "on the record," but the only real change in delta-vee I've seen is that it's dropped a little with practice. I've done maybe a dozen full runs, varying different things, and RCS remaining always comes out around 280 to 282 kg. The worst was I did that "bad situation" run I described earlier (radar broken, Rinc=0.09), but I had 278 kg left at the end. So I don't think there's anything engraved in stone about the 37 km number.

With all that said, let me lay out what I'm thinking for the next version.

As it stands, there are too many MCCs. I didn't know how many MCCs the real Gemini did, so I just said "start doing them and keep doing 'em." Lunney's paper implies that they did two MCCs (see his figure 3) but makes no further statement, and I didn't want to take some marks on a graph as gospel until I had further confirmation. I've now found source that confirms that there were two (Dave Scott discussing Gemini 8 in a 1966 interview), but still have no idea at what times after TPI those were done. (You'd think that with all the inquiries NASA must get from us, they'd have an Orbinaut Liaison Officer by now. :lol: )

So as long as the raw trajectory takes a little over a half hour, if I can't locate more specific historical data then I'm thinking of just specifying two MCCs with 2:00 measurements centered at 10:00 and 20:00. That works out to nice round numbers; the expected angular motion is 4.051 deg. from 9:00 to 11:00, and 0.953 from 19:00 to 21:00, which is close enough to call 4 degrees and 1 degree. For a nominal trajectory, the ranges at 10:00 and 20:00 are 28.9 and 11.3 km respectively, so both are within "Aldrin's limit" if anyone is worried about that.

This would also make the technique easier to generalize. Aside from the initial TPI parameters, the only two parameters necessary would be expected angular motion from 9:00 to 11:00, and from 19:00 to 21:00, and both those could probably be well-represented by linear functions of target (or active) craft radius and delta-H.

I haven't tried doing any runs with those parameters, but will take a few cracks at it and see how it goes. If anyone else wants to give it a shot and see how I'd goes, I'd appreciate hearing about it.

Also, on getting into a coelliptic configuation with the target craft. I've found an Orbiter-friendly way to do that, even with non-spherical gravity turned on. My lunch hour is rapidly closing out on me and I'd like to grab a sandwich, but if anyone wants that procedure I'll describe it here.

SAM

 

[pattersoncr]

The transfer time is always the same? That's amazing! I would have thought it got longer with a higher orbit (therefore longer orbital period therefore longer time to travel 130deg).

It sounds like this will simplify quite nicely:
1. A small table that gives dV and pitch angle for the TPI burn.
2. A table for each MCC that gives dV based on range and angle error.

I'd like to hear more about the coelliptic setup.

 

[Sam]

The transfer time is always the same? That's amazing! I would have thought it got longer with a higher orbit (therefore longer orbital period therefore longer time to travel 130deg).

Well, that's if the active craft's radius is held constant. The active craft has to travel 130 degrees, the target craft goes a little less. With the active craft radius the same, the transfer time isn't too sensitive to delta-H -- 1 km vs 300 km is only a minute or so difference. Still, that's pretty wild; the first time I saw that I rechecked the numbers twice, thinking I had screwed it up.

It sounds like this will simplify quite nicely:
1. A small table that gives dV and pitch angle for the TPI burn.
2. A table for each MCC that gives dV based on range and angle error.

I had a go at the 2 MCC (10 and 20 minutes) procedure last night and it didn't do too well. With the "bad case" scenario I used earlier the procedure utterly failed. With the tutorial's optimal-conditions SCN it worked and I had 284 kg RCS remaining (typical for me is ~282), but the target's apparent motion was pretty wild at the end. A naive newbie trying the procedure and seeing that would think that either (a) he or she had failed, or (b) the procedure was nothing more than a glorified way of brute-forcing ones way in.

I understand that for a generalized procedure an experienced pilot could probably do it by "feel" and get good results, but I'd like the actual tutorial to be educational and so getting the "straight-in" result through an organized and systematic procedure is pretty important to me. It could very well be that the lesser precision of Orbiter's "sextant" means more MCCs are necessary for that. I'm putting together a pretty big "test flight" that I'll do in the next couple of days (basically trying to replicate the 4-orbit rendezvous plan Lunney describes). One thing I'll do is try the 2 MCC scheme again with Telescope MFD for better precision and see if I can get a better idea of whether its a precision problem or if the 2 MCC idea itself is flawed.

I'd like to hear more about the coelliptic setup.

The thing that was driving me batty earlier was that I was trying to do that maneuver in what might be called "classic" Orbiter style; get to the target's periapse or apoapse and make a prograde or retrograde burn, etc. With non-spherical gravity that doesn't work at all. By the time you get to where you think the target's apses are supposed to be, perturbation has flung them around to some other place. Here's what I ended up doing. It's crude and a little wasteful of fuel, but it works.

To get the idea, consider three things. First, the coelliptic maneuver would be done only after phasing ("sync orbit") and plane alignment maneuvers and would be the last thing before TPI, probably done less that an orbit before TPI.

Second, the delta-H is small. So the active craft and target radii has nearly the same SMas; orbital periods are nearly the same; and the active craft is slowly creeping up on the target.

Put those two thing together and that means a low phase angle (TrL difference) and phase rate (how much TrL difference the active craft "catches up" per orbit. With delta-H=24 km the phase angle at TPI will be about 0.4 and the phase rate is about 2 degrees per orbit. If this maneuver is done a quarter orbit before TPI, the phase angle at that point is 0.4 + (2/4) = 0.9 degrees, and each craft is moving about 1 TrL degree every fifteen seconds.

Third, the active craft's orbit would already very roughly match the target's orbit. For example, if rendezvousing with ISS which has low eccentricity, the active craft would be in a roughly circular orbit. That circularization might have happened just seconds before this maneuver, but it's still happened.

So, you're 1/4 orbit before TPI, phase angle of a degree or less. You're already coplanar with the target, so no worries there. At the moment you're at or about your desired delta-H below the target. To get coelliptic you'll need to match LPes, and match differences in PeR, ApR, and SMa.

Phase angle matters to the 1/100th of a degree for other parts of the overall historical NASA rendezvous scheme. But for the logic of this maneuver it's close enough to not matter. You're at the same TrL, and that means that with the same LPes you'd have the same true anomaly, TrA, as the target. And with the same TrAs, if orbits are matched for PeR, ApR, and SMa, the relationship between your Rad and your SMa should be the same as the relationship between the target's Rad and its SMa. If the target's Rad is 3 km less than its SMa, your Rad should be 3 km less than your SMa. So --

--- Step 1 is to turn on prograde auto then burn prograde or retrograde to make your (Rad - SMa) match the target's (Rad - SMa). Now your velocity magnitude is what it needs to be, but your velocity direction may not be; e.g., you might be headed down toward periapse while your target might be climbing.

--- Step 2 is to make velocity direction right. Burning perpendicular to your velocity vector and in the orbit plane will move your velocity direction so that it matches the target. The easiest way to me is to look at the LPes, give a short blast of left or right RCS LIN (prograde auto is still on) to see which way moves the LPes closer, then blast in that direction to bring 'em in line. RCS LIN seems to work well enough for small adjustments; if LPEs are far apart you might have to do a gross adjustment by rolling 90 degrees and using hovers. This step will also make the PeR and ApR differences fall into line.

-- Step 3 is go back to step 1 if necessary and re-tweak. One or two iterations should be all you need to put PeR, ApR and SMa differences within +/- 1 km, and LPes within a degree.

With that configuration you'll still get smacked around by non-sph. grav, perturbation, etc., but the target will be experiencing the same effects, so the coelliptic relative configuation ends up being pretty stable. I've done a couple of trial runs using this procedure to put myself coelliptc with ISS then fast-forwarding through two or three orbits to see what happens, and PeRs, ApRs, and SMas stay within +/- 1 km of where they need to be; Rinc doesn't seem to change at all; and LPe differences flop around somewhat but stay within about 10 degrees. From what I've seen already that's close enough for the subsequent TPI and rendezvous procedure to work.

SAM

 

[Sam]

I had a go at the 2 MCC (10 and 20 minutes) procedure last night and it didn't do too well. [...] I'd like the actual tutorial to be educational and so getting the "straight-in" result through an organized and systematic procedure is pretty important to me. It could very well be that the lesser precision of Orbiter's "sextant" means more MCCs are necessary for that. I'm putting together a pretty big "test flight" that I'll do in the next couple of days (basically trying to replicate the 4-orbit rendezvous plan Lunney describes). One thing I'll do is try the 2 MCC scheme again with Telescope MFD for better precision and see if I can get a better idea of whether its a precision problem or if the 2 MCC idea itself is flawed.

Aggh ... I noticed last night when time-accelerating that my sighting platform (the allegedly KILLROTed DG) was slowly turning. :lol: I found that my KILLROT technque was somewhat sloppy; I've been whipping around between KILLROT, RCS LIN and RCS ROT pretty quickly and occasionally the rotation doesn't quite get killed. But another cause I found was that I had gravity-gradient torque turned on. I guess that's a no-no.

After I fixed that I decided to take the measurement error out altogether and see how things went. I did three runs with the 2 MCC version of the technique (9-11, 19-21 minutes). At the beginning and end of each measurement I quicksaved, then after the end measurement I paused, yanked the RPOS and RVEL lines from the SCNs and calc'd the apparent motion directly from them; then did the MCC according to that. Things went fine.

Then did a rendezvous with ISS. Non-sph grav on; manually entered into coelliptic orbit instead of setting up the SCN to have me there already; used eyeball measurements for the two MCCs; but intentionally making a bad TPI burn with both out-of-plane and in-plane errors (aimed ~15 degrees to the side of ISS instead of ~8 degrees below). Same result; no problems, straight in at end, etc.

So the 2MCC generalization is looking a lot better.

SAM

 

[tblaxland]

Aggh ... I noticed last night when time-accelerating that my sighting platform (the allegedly KILLROTed DG) was slowly turning. :lol: I found that my KILLROT technque was somewhat sloppy; I've been whipping around between KILLROT, RCS LIN and RCS ROT pretty quickly and occasionally the rotation doesn't quite get killed. But another cause I found was that I had gravity-gradient torque turned on. I guess that's a no-no.

Hmmm, sounds like you could use a Sextant MFD. I'm not sure about graphics but to measure the altitude of an object above the local horizon in Orbiter is fairly easy. Interested?

 

[Sam]

Hmmm, sounds like you could use a Sextant MFD. I'm not sure about graphics but to measure the altitude of an object above the local horizon in Orbiter is fairly easy. Interested?

Hey, I'll take all the help I can get! Now with that said ...

If something like that already exists and you can point me to it ... or if you're offering to put one together and it's very little trouble to do so, then OK. But if you're offering to put one together and it's more than a few moments work, then let me suggest you don't do it just yet (unless of course you're doing it for other reasons anyway).

The reason is, horizon-relative or local-horizontal-relative angle isn't what's needed here. That only comes into play for timing the TPI burn (surf hud +26).. After that, it's not needed at all, the task is measuring the apparent motion of the target craft and separating that into in-plane vs out-of-plane components. And to make things even weirder, the "plane" isn't the real orbital plane, it's what the pilot must assume is the orbital plane without other instrumentation available (the plane defined by local vertical and target's apparent position).

I've put together something that will do that for me with data snagged from quicksave files. It's several vector cross products, dot products, etc, and it's fairly simple, but it's got a few "gimbal lock" conditions in it. Now, as long as I'm just using that to check results and stuff, and I can directly see if one of those screwy conditions applies at any given time, that's fine -- I'm only using it to "debug" the procedure anyway.

But I think (not sure at all yet) that to put something more reliable together for general usage would require doing stuff with AROTs and Euler's rotations. The last time I tried working with that stuff, the medics found me lying on the floor unconscious with blood dripping out of my ears ... and I'm not even sure that's what's needed here.

So that's where I'm at. Thanks!

SAM

 

[tblaxland]

If something like that already exists and you can point me to it ... or if you're offering to put one together and it's very little trouble to do so, then OK. But if you're offering to put one together and it's more than a few moments work, then let me suggest you don't do it just yet (unless of course you're doing it for other reasons anyway).

I'm offering to put something together because it shouldn't take much work (for something text-based anyway).

The reason is, horizon-relative or local-horizontal-relative angle isn't what's needed here. That only comes into play for timing the TPI burn (surf hud +26).. After that, it's not needed at all, the task is measuring the apparent motion of the target craft and separating that into in-plane vs out-of-plane components. And to make things even weirder, the "plane" isn't the real orbital plane, it's what the pilot must assume is the orbital plane without other instrumentation available (the plane defined by local vertical and target's apparent position).

OK then. I really need to get in and do the actual rendezvous now to get a better appreciation of of the required measurements. I got the impression from your earlier commentary that they did those measurements with a sextant anyway. If it was done with a sextant in the real world, I'm pretty sure I can make an MFD to do the same measurements. If not, I think I can do it anyway.

Idea: what if we put range and range-rate data in there too, so you don't need the Docking MFD open at the same time. A sextant and rendezvous radar in one instrument would pretty well simulate the instruments available to the pilot.

The last time I tried working with that stuff, the medics found me lying on the floor unconscious with blood dripping out of my ears ... and I'm not even sure that's what's needed here.

It may be a few days before I can get to do an actual rendezvous, then I will have a better feel for what is needed. If you have any other ideas in the meantime, let me know.

 

[Sam]

I'm offering to put something together because it shouldn't take much work (for something text-based anyway).

LOL -- Easy for you; way over my head. I wouldn't have the faintest idea how to write an MFD. As far as text-based vs. something snazzier, I like the idea of this as just a text-based MFD. To me, the idea of simming a low-tech approach implies that the displays should not look like something from the bridge of Captain Picard's starship, but more like a VT-100 terminal. (Anyone else old enough to actually remember those?)

If you have any other ideas in the meantime, let me know.

Hmm ... Of course you realize that immediately after you release this, someone's gonna use it to try to celestial navigate to Mars. I don't know if you're thinking of the as a one-shot deal for this particular situation or as a possible version-1 of something that would have more general applications, so I'll just lay out some thoughts, disclaimers, etc. for you to consider or disregard as you see fit. Whatever way you go, I can certainly incorporate it into what I'm doing. And again, thanks!

When I released the tutorial, I thought the big kick for users would be "I just did what Lovell and Aldrin did, pretty much the same way they did it." But from what feedback I've got so far from the people who've taken an interest in this, there seems to be more of a desire to generalize this to other situations -- rendezvous with ISS, etc. So for the next tutorial iteration I think I'm going to use the included scenario as a basic demonstration, then go from there to a general method for planning and executing a visual rendezvous. Now, the only way I know to do that right now is this way. So any "Gemini-specific" comments I'm making, particularly regarding the apparent motion of the target and its measurement, also apply to the general technique.

I really need to get in and do the actual rendezvous now to get a better appreciation of of the required measurements.

One correction I've gotta make to the tutorial concerns the craft's orientation while taking measurements and making MCCs. The correct attitude is with the nose on the target and Orbit HUD's "latitude lines" straight up and down (see attached JPG). In the tutorial I said that the Surface HUD lines were the correct reference, and they're not. For the tutorial example it doesn't matter, because the active and target craft are coplanar and it works out to the same thing. But for off-plane situations, it does matter.

Off-plane corrections are done the same way as in-plane corrections, except that the expected angular motion is zero. So if the expected drift over two minutes (9:00 to 11:00 past TPI) was 4 degrees down; the observed motion was 2 degrees down and 1 degree left; and the range @ 10:00 was 30 km; the MCCs would be:

(2 degs higher than expected ) * (30 km) / (2 minutes) = 30 seconds RCS_LIN up
(1 degree left) * (30 km) / (2 minutes) = 15 seconds RCS_LIN left

As it turns out, I misunderstood the situation earlier and ended up doing off-plane MCCs the right way for the wrong reasons. The active craft's vertical axis should not be in the plane defined by the local vertical and the apparent position of the target (normal vector = ACT_RPOS X TGT_APP_POSN). Instead the active craft's vertical axis should be in its own orbital plane (normal vector = ACT_RPOS X ACT_RVEL), with the nose pointed directly at the target (and I've confirmed this with other sources). That implies a slight cheat, in that the Orbinaut is indirectly using information obtained directly from Orbiter's physics engine, but I don't think it's a serious one.

The math's attached here. Fixing my earlier misunderstanding also fixed the gimbal lock problem I was running into, and as far as I can tell this math should work for any situation. I haven't tried it with extreme out-of-plane angles, though.

I got the impression from your earlier commentary that they did those measurements with a sextant anyway. If it was done with a sextant in the real world, I'm pretty sure I can make an MFD to do the same measurements.

They did, but I'm not sure exactly how they used it; what they were measuring the target's motion against. I do know that they took the measurements when the craft was essentially KILLROTed, and that there was no stabilization for the sextant other than the pilot's hands. (One comment Aldrin made after Gemini XII was that doing the measurements in orbit was easier than the sims in one way; in zero-g, the pilot's arms didn't get tired from holding the six pound sextant up.)

I can see two ways to go about it. One would be to do traditional sextant measurements, directly measuring one angle at a time, noting the time of each measurement, and making each measurement relative to a specific reference point -- e.g., at time T1 the target was angle A1 from Pollux, at time T2 the target was angle A2 from Castor, etc., then doing the math from there. That's fine for a mariner who can do the math at leisure below decks, but it seems a bit much even for experienced astronauts to do during a half-hour rendezvous trajectory. Maybe if the inertial platform was out but the flight computer and radar were still working; other than that, no.

The condition simulated in the tutorial is that the flight computer is broken, not the inertial platform. Under those conditions it makes more sense to me to use a method Aldrin contemplated in his dissertation; orient the sextant's field of view so that in-plane is straight up-and-down, center the target, then hold the FOV's stellar background steady while timing the target's motion away from the center. Essentially that's what I'm doing here.

Now with all that said, I don't know exactly what they did, I'm just guessing out loud. But that makes sense to me.

Idea: what if we put range and range-rate data in there too, so you don't need the Docking MFD open at the same time.

I was thinking the exactly same thing. Also, the real rendezvous radar gave the target's angular location away from the craft's nose -- e.g., it told the astronauts that the Agena was 4 degrees right and 7.6 degrees up. I wouldn't expect anyone to give up planetarium mode, but sometimes it's hard finding a small target that's only visible at 10 FOV or even smaller (w/Telescope MFD), so that could come in handy.

On sextant usage in general. Measuring a star's angle from local vertical can be used to establish the orbital plane. For example, let's say your orbit is circular with a 100 minute period and you take two measurements of the local vertical/Polaris angle 10 minutes apart. If your EQU Inc is 90 degrees, those angles will differ by 36 degrees; if EQU Inc is 0 degrees, the angles will be the same; etc. And of course it's also useful for this specific situation; +26 on the Surface HUD is just another way of saying 64 degrees off local vertical.

Although horizon-relative angles don't come into play in this specific situation, Gemini did have that capability, although I'm not sure how accurately those measurements could have been made. The crafts did have "horizon locators" which compensated for the fact that it's hard to locate Earth's horizon from above the atmosphere; that instrument detected a range of infrared wavelengths which gave a reliable indication of a 30 km altitude "pseudo-horizon" regardless of what clouds, etc. happened to be in the way. I do know that one thing they could have been used for was to establish local vertical if the inertial platform failed, but I don't know what other uses NASA had in mind for them. Since they read scattered sunlight, they only worked on the daylight side of Earth.

A couple of miscellaneous "fun facts." The Gemini rendezvous radar had a maximum range of 250 nm (Apollo's was 400 nm), and only gave directional information if the target was within about 25 degrees of straight-ahead. The sextant's maximum measurement was 76 degrees.

Anyway, my two recommendations for the MFD are:

1) with a user input to define the start of measurement time, the MFD should define the measurement plane as described (essentially incorporating part of the inertial platform into the sextant), then display elapsed time, in plane motion, and out of plane motion of the target. The ability to freeze that display at the end of some elapsed time would be nice, but isn't essential.

2) the MFD should display the angle from local vertical for a selected target (no partitioning of in-plane vs. out-of-plane components).

As for anything beyond that? ... My impression is that what I'm working on has a fair number of "curious onlookers," but only a handful of people with a more-than-casual interest. There's no implied complaint or disappointment there; there are a lot of people interested in a lot of different things, and I'm perfectly happy working with just a few people who are intrigued by the same things I am. I'm just saying that I haven't seen any indication that a general interest in navigation-by-sextant is catching on; if it does, I'm sure others will come up with more ideas.

SAM

 

[tblaxland]

As far as text-based vs. something snazzier, I like the idea of this as just a text-based MFD. To me, the idea of simming a low-tech approach implies that the displays should not look like something from the bridge of Captain Picard's starship, but more like a VT-100 terminal. (Anyone else old enough to actually remember those?)

Good, easier for me to write then :speakcool:. BTW, the VT-100 was just shortly before my introduction to computers.

Hmm ... Of course you realize that immediately after you release this, someone's gonna use it to try to celestial navigate to Mars.

Lol, half their luck if they make it. I'll deal with it like I do for other LGPL projects: "Sextant MFD is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."

That implies a slight cheat, in that the Orbinaut is indirectly using information obtained directly from Orbiter's physics engine, but I don't think it's a serious one.

Not serious at all I think, because all it means is that you are finding the orbital plane from the HUD, instead of from the local horizon. That is something that is difficult to do in Orbiter where you don't have a real sextant to find the horizon with. The main motivation behind Sextant MFD is to simulate a measurement platform that is stabilised relative to an inertial frame so that your vessel does not have to be so stable.

The math's attached here.

That looks pretty similar to what I had in mind and it has served to clarify for me what the measurement frames are.

They did, but I'm not sure exactly how they used it; what they were measuring the target's motion against.

I'm a little confused on that too. Your calculations imply that it is relative to an inertial frame that has its orientation reset at the start of each measurement cycle such that it is coincident with the LVLH frame at that time.

Also, the real rendezvous radar gave the target's angular location away from the craft's nose -- e.g., it told the astronauts that the Agena was 4 degrees right and 7.6 degrees up. I wouldn't expect anyone to give up planetarium mode, but sometimes it's hard finding a small target that's only visible at 10 FOV or even smaller (w/Telescope MFD), so that could come in handy.

Can be added without too much difficulty.

A couple of miscellaneous "fun facts." The Gemini rendezvous radar had a maximum range of 250 nm (Apollo's was 400 nm), and only gave directional information if the target was within about 25 degrees of straight-ahead. The sextant's maximum measurement was 76 degrees.

I guess those limitations could be programmed in for fun (available through config file option).

1) with a user input to define the start of measurement time, the MFD should define the measurement plane as described (essentially incorporating part of the inertial platform into the sextant), then display elapsed time, in plane motion, and out of plane motion of the target.

Agreed.

The ability to freeze that display at the end of some elapsed time would be nice, but isn't essential.

Like a lap timer?

2) the MFD should display the angle from local vertical for a selected target (no partitioning of in-plane vs. out-of-plane components).

Can do.

I'm just saying that I haven't seen any indication that a general interest in navigation-by-sextant is catching on; if it does, I'm sure others will come up with more ideas.

That's OK. I tend to find it easier to motivate myself to write these things when I am interested in them. If others are too, that's a bonus.

 

[Sam]

They did, but I'm not sure exactly how they used it; what they were measuring the target's motion against.

Sorry, I could have stated that better. I'm 99% sure they were measuring the target's motion relative to that frame. What I'm not at all sure of is what their raw measurement data looked like -- angles between the target and specific reference stars at specific times? align the sextant, center the target, and time how long it took the target to drift to a reticle mark? etc. I don't think it matters for this purpose, though; as far as I can see this is the only practical way to measure the apparent motion in Orbiter, and the idea of stabilizing an optical sight wrt to craft's inertial platform is far from fanciful.

I'm a little confused on that too. Your calculations imply that it is relative to an inertial frame that has its orientation reset at the start of each measurement cycle [...]

Right, that's it exactly.

[...] such that it is coincident with the LVLH frame at that time.

Hmm ... I think we're in agreement but I'm not sure exactly what you mean by that, so I'll just restate it but rephrase it a different way. At the start of the measurement, point the nose of the active craft directly at the target. Then roll the active craft until its vertical axis lies in its own orbital plane. That makes the in-plane motion up and down from the pilot's perspective, and out-of-plane motion is seen as left and right. There are two ways that can happen, one with the act. craft's ceiling pointed in the correct direction, the other 180 degrees roll from that so that the craft's belly is pointed where its ceiling should be. The correct one is where the ceiling is pointed at TGT_APP_POSN_0 X (ACT_RPOS_0 X ACT_RVEL_0), so that "left" and "up" don't end up where "right" and "down" should be. The craft's vertical axis will be in the orbital plane, but probably won't be the same as local vertical.

Like a lap timer?

Naah, actually I just meant a "stop" button for the end of measurement, to freeze the display at "2:03, 4.25 down, 0.16 left" or whatever. I guess that would be essential; I'm not sure what I was thinking when I wrote that. :lol:

SAM

 

[tblaxland]

At the start of the measurement, point the nose of the active craft directly at the target. Then roll the active craft until its vertical axis lies in its own orbital plane. That makes the in-plane motion up and down from the pilot's perspective, and out-of-plane motion is seen as left and right.

:face-palm: Got it now. Except that instead of aligning the vessel's axes that way, I am aligning the sextant's axes instead. Obviously, the vessel's axes would still need to be close to your described orientation for the MCC's to be effective but I will leave that for the pilot to take care of.

Naah, actually I just meant a "stop" button for the end of measurement, to freeze the display at "2:03, 4.25 down, 0.16 left" or whatever. I guess that would be essential; I'm not sure what I was thinking when I wrote that. :lol:

OK, that is easy then. I could make it stop automatically at 2 minutes (or whatever interval) if you like.

 

[tblaxland]

Update - I've got some documentation on OrbiterWiki and a basic layout done:

Any comments would be appreciated. That's enough for now, I'll get into the inner workings in a couple of days time.

 

[Sam]

Wow, that looks terrific! I hadn't thought at all about what happens if you quicksave and reboot in the middle of the measurement interval, but I see you're way ahead of me on that (saving data to SCN).

To keep you in the loop on what I'm doing ... I'm still working on the linear equations for the TPI burn, MCCs, etc. Getting the equations is simple enough, but my concern is the error they carry along with them.

Consider two extremes for how the final product might look. At one extreme, you'd have a single set of five equations -- range @ TPI; delta-vee of TPI; direction of TPI; expected apparent motion for MCC#1; exp. app. mot. for MCC#2. That would be very simple to use but wouldn't be too accurate, and rendezvous with those parameters wouldn't be too reliable.

At the other extreme, you might have those five equations for every possible combination of target radius and delta-H; a set of five equations for (6831 km; 45 km), another for (6664 km; 17 km), etc. The result would be very accurate, but the tables would be horribly bulky and nobody would ever use it.

What I'm trying to do is come up with a set of equations like <parameter> = C1 * target_radius + C2 * delta_h + B, for each of the five parameters, which could be used over the broadest ranges possible. For example, the table might specify something like:

TPI delta-vee magnitude:
If target radius >= 6700 km and < 6800 km, C1 = ##, C2 = ##, B = ##
If target radius >= 6800 km and < 6900 km, C1 = ##, C2 = ##, B = ##.
[etc]

Essentially something like what Chuck described earlier, except with only two scheduled MCCs. (Note that all five parameters could be calculated well in advance of the actual rendezvous maneuvers). I think that whatever I come up with I can fit on one page. That would also have a nice analog to maritime navigation. From what I understand, at one time (and maybe even today?) emergency lifeboat supplies had a more durable but less accurate sextant (similar to a modern plastic training model) and a laminated paper with simplified tables. Enough to get you close enough to where you wanted to be that you could navigate your way in with coastal references, etc. This would be part of something similar -- you're in orbit but your primary instruments have gone out, here's how you get back to ISS.

Anyway, what I'm working on now is a Monte Carlo simulation. Start from relative orbits that aren't quite perfect, do the procedure using the derived (C1, C2, B) sets, introduce reasonable errors along the way (initial orbit coellipticity, timing of burns, etc.) and see how wide I can make the table intervals (100 km in the above example) while still having simulated orbits that reliably go to a successful rendezvous. Lucky we have modern CPUs and for() loops! -- my middle-of-the-road PC can do about 6500 starting configurations per second (calculate and verify Lambert solutions, delta-vees @ TPI and rendezvous, etc.).

SAM

 

[tblaxland]

OK, that is easy then. I could make it stop automatically at 2 minutes (or whatever interval) if you like.

I've been thinking about this and I won't be planning on implementing this option (at least for now). There are two reasons: firstly, it makes it easier , and; secondly, it seems from what you have described that the measurement interval will not always be constant.

Wow, that looks terrific! I hadn't thought at all about what happens if you quicksave and reboot in the middle of the measurement interval, but I see you're way ahead of me on that (saving data to SCN).

Hmm, I hadn't planned on saving measurement data, just settings (reference body and target body), but I'll see what I can do. Your comment did make me realise one thing I should do: make it so you can start a mark, switch focus to another vessel, then come back a little later and finish the mark.

[...snip: lots of good stuff...]

That all sounds great. Possible next step - tables for other bodies? (most notably the Moon). Sextant MFD will support it, BTW.

---------- Post added at 10:52 ---------- Previous post was at 09:48 ----------

At the start of the measurement, point the nose of the active craft directly at the target. Then roll the active craft until its vertical axis lies in its own orbital plane. That makes the in-plane motion up and down from the pilot's perspective, and out-of-plane motion is seen as left and right.[...]The craft's vertical axis will be in the orbital plane, but probably won't be the same as local vertical.

I have been thinking further on this and believe there is a slight error here. Firstly, to decouple the sextant from the vessel I am going to define a "measurement frame" which is an inertial frame of reference and is aligned in a certain way relative to the active and target vessels.

Based on your description above, the measurement frame should have its +Z axis pointing at the target and its +Y axis lying in the active vessel's orbital plane at t=0. The problem I have with that is that for target's high above the local horizontal plane and with large relative inclinations to the active vessel, the more the active vessel would need to be rolled away from a "heads-up" attitude. This is inconsistent with your earlier statement that the latitude lines in the orbit HUD should be vertical.

I think what we want is for the measurement frame to be oriented such that, at t=0, the +Z axis points at the target and the +X axis lies in the active vessel's local horizontal plane. This is also consistent with the normal sextant operation of holding the sextant vertical. The above two approaches converge for cases where the active and target vessels are co-planar. Also, for any reasonable rendezvous targeting, the difference between the two would most likely be negligible. I guess I am just trying to be thorough

Side question: when the astronauts were using the sextant in the Earth's shadow, how did they find the horizon? Is it still visible due to atmospheric scattering or is the IMU aligned with the orbital plane? I don't think they used the horizon scanners (BTW, despite your earlier comment, I think they would still work on the dark side since the atmosphere/Earth is a *lot* warmer than the background).

 

[Sam]

Possible next step - tables for other bodies? (most notably the Moon).

Yeah, unless I'm really missing something here, I think that to do this for other bodies wouldn't take much more than plugging in the new central body's mass, re-running the same programs, and collecting the results. With lunar orbit radii about 1/4 of LEO radii, it might be that smaller intervals will be necessary; maybe one set of C1/C2/B per 25 km range instead of per 100 km range as in the LEO example.

when the astronauts were using the sextant in the Earth's shadow, how did they find the horizon? Is it still visible due to atmospheric scattering or is the IMU aligned with the orbital plane?

AFAIK, they didn't. I'm pretty sure they checked and aligned their inertial platform every chance they got, so they could have got local vertical and horizontal from that. But sextant sights using the Earth's horizon wouldn't have been any use to them in this sort of trajectory anyway. Bearing in mind that the maximum angle that could be measured with the sextant was 76 degrees, look at fig 3.4, page 9 of the tutorial, and you'll see why horizon angle measurements wouldn't have worked for this.

The report I read of the in flight sextant experiments and the ground training didn't mention any horizon-relative angle measures. The ground training used two lights to simulate 2nd magnitude stars. In flight the measurements were star-to-star (e.g., angle from Rigel to Betelgeuse) and a failed attempt to measure Moon-star angles -- the Moon's apparent position was too close to the Sun, and that messed things up.

Also, for any reasonable rendezvous targeting, the difference between the two would most likely be negligible. I guess I am just trying to be thorough

No problem. I had it wrong a few posts back when I said that the plane was the one formed by the target's apparent position and local vertical, and I'm sure that by saying that I haven't helped things any. And I was running math checks on simulator runs using that incorrect frame for a while and getting what looked like valid results. You're right, for any relative inclination that's low enough for a reasonable rendezvous, the different frames all produce about the same numbers.

Try this experiment with Orbiter -- in orbit, turn on prograde autopilot and let your craft stabilize there. Now turn off the autopilot and roll 90 degres so that you're still pointed prograde, but you're "wings level" with the central body below you, and the orbital plane pointing straight up and down from your perspective. With Orbit HUD on, you'll see the HUD's "latitude lines" go straight up and down. Now, starting from that orientation ...

1) yaw left or right. Let the craft turn a full circle. The HUD's latitude lines will stay straight up and down.

2) same as #1, except before yawing, pitch some arbitrary angle then KILLROT. So now you're going to start yawing with the nose pointed at, say, "48 degrees longitude, 0 latitude" on the Orbit HUD, and the latitude lines oriented straight up and down. When you yaw, the latitude lines will still stay in that orientation.

Consider this example. Let's say you were at the center of the Earth, tracking the motion of some object at 48W, 45S. You might start by orienting yourself so that you were looking straight ahead at 0 long, 0 lat, and with the North Pole directly to your left. From that orientation, you could pitch up so you were looking at 48W 0S with the N. Pole still to your left. At that point, the "horizontal plane" for you would be the 48W/132E circle of longitude. Then you could yaw right 45 degrees and direct your sight at the target T (attached fig_1).

From that orientation, if T made any change in longitude, you'd see it as up/down motion. Any changes in T's latitude would be seen by you as left/right motion. You would be in the equatorial plane, passing straight up and down through you, and the 45S latitude circle would be part of a plane that was parallel to your equatorial plane. To you, "left" would point toward 48W, 45N, as shown in the figure, and "up" would point straight out of the page, toward 138W 0N -- in the equatorial plane.

Now, as long as you don't move from that position, the 45S latitude line near T will look vertical to you. If you pitch from that attitude, it won't stay vertical -- your "forward" will trace out a great circle all the way over to 132E 45N, then back, and the latitude lines will flop around from your perspective. But that sort of pitch maneuver isn't involved here -- your orientation is fixed on the target's initial position, measuring latitude change (apparent left/right motion) and longitude change (apparent up/down motion).

The attached fig_2 shows the same thing in orbit. The larger illustration is as seen from just behind the active craft in orbit; the smaller illustration to the lower right is as seen from the anti-normal direction. The light blue line is the active craft's local horizontal, and the target craft is elevated from it by 48 degrees. The ellipse in the large illustration, and the corresponding black line in the small illustration, are the same -- the plane formed by the target's relative position and the normal/antinormal lines -- analagous to the 48W/132E plane in fig_1. The target is being tracked relative to a plane (big illustration's dark blue line) that includes T and is parallel to the active craft's orbital plane. To do this, the active craft is placed in the orientation so that T's "blue plane" (an Orbit HUD latitude line) is straight up and down from the active craft's perspective. T's in-plane motion will be seen by the active craft as up/down motion, and T's out-of-plane motion will be seen as left right. The active craft's vertical axis is in its own orbital plane (light green), and the active craft's "left" is not in its (light blue) horizontal plane.

I think that if this scheme fails anywhere, it's going to be if the target is near the normal or anti-normal vectors. At that point, a small change in apparent position can result in large and somewhat non-sensical (for this purpose) changes in "longitude" and "latitude." But if the target's at that apparent position, it means that the active craft is passing it by and is well to the side of it, which pretty much means that the pilot has blown the rendezvous anyway.

BTW, despite your earlier comment, I think [horizon locators] would still work on the dark side since the atmosphere/Earth is a *lot* warmer than the background

Could very well be; I was going by some technical document from the planning stages, but I don't have any information on how they actually worked in flight.

SAM

 

[Andy44]

Great thread. Back when I first downloaded Orbiter I was looking to play around with stuff like this. Real astronaut stuff. Can't wait until I get some time to try this out. Along with my manual moon landing techniques this will come in handy for flight sim fun. Greg Burch is probably right when he envisions a future with mostly autopilots, since good flight software can do these tasks in the most fuel-efficient manner, but there is a bit of Heinlein and Aldrin in every space pilot that keeps him training for this.

Buzz, hope you lurk the Forum...

 

[tblaxland]

OK, I get the measurement frame alignment now. The "centre of the Earth" example helped a lot, thanks.

Another question about the real-world measurements:

The report I read of the in flight sextant experiments and the ground training didn't mention any horizon-relative angle measures. The ground training used two lights to simulate 2nd magnitude stars. In flight the measurements were star-to-star (e.g., angle from Rigel to Betelgeuse)...

How did they deconvolve measurements of the target movement in-plane/out-of-plane measurements?

 

[Sam]

Great thread. Back when I first downloaded Orbiter I was looking to play around with stuff like this. Real astronaut stuff. Can't wait until I get some time to try this out. Along with my manual moon landing techniques this will come in handy for flight sim fun. Greg Burch is probably right when he envisions a future with mostly autopilots, since good flight software can do these tasks in the most fuel-efficient manner, but there is a bit of Heinlein and Aldrin in every space pilot that keeps him training for this.

Thanks! I'm all for autopilots, nav computers, etc., but every once in a while I've gotta at least try to feel like I'm really flying with just stick-n-rudder.

Buzz, hope you lurk the Forum...

As a gag, I thought about referring to Aldrin and his dissertation in the tutorial with ecclesiastical capitalizations, and putting His Words in red. Something like this:

On page 133 of The Book, He said, "[T]he general approach is to obtain a value for the average angular rate error that has existed since the sight was last aligned ..."

Alas, discretion prevailed. If he ever does lurk, it's probably a good thing I didn't. :lol:

The "centre of the Earth" example helped a lot

I've been trying to wrap my mind around all this, making paper airplanes and twisting them around in the air, etc. That example was the analogy I finally ended up constructing to explain it to myself, so I couldn't let it go to waste.

How did they deconvolve measurements of the target movement in-plane/out-of-plane measurements

For those particular examples? Ya got me. The star-to-star angles would have been constant, and I think were taken just to get a baseline of pilot accuracy. The Moon-to-star measurement sounds to me like prepwork for Apollo's trans-lunar trajectory, and not something that would be directly useful for LEO in Gemini, but I'm just guessing at that.

SAM

 

[tblaxland]

On page 133 of The Book, He said, "[T]he general approach is to obtain a value for the average angular rate error that has existed since the sight was last aligned ..."

:rofl:

For those particular examples?

No, no, for the case we are looking at, ie, measurement of the motion of the Agena. I can see how they would measure its absolute relative angular motion but how to deconvolve that into in-plane and out-of-plane components when viewing the motion against the background stars? All I can think is that the alignment of the sextant axis was eye-balled against their own orbital plane, but that doesn't seem accurate enough. That said, your original tutorial involves eye-balling it and it works OK.

 

[Sam]

No, no, for the case we are looking at, ie, measurement of the motion of the Agena. I can see how they would measure its absolute relative angular motion but how to deconvolve that into in-plane and out-of-plane components when viewing the motion against the background stars? All I can think is that the alignment of the sextant axis was eye-balled against their own orbital plane, but that doesn't seem accurate enough. That said, your original tutorial involves eye-balling it and it works OK.

Ah, ok ... that's what I get for trying to think at 2 AM. :rofl:

First I gotta go back to my usual disclaimer -- I don't know exactly what they did, I've tried to put together a plausible method of how it might have been done, calling into play the same principles that would have applied, etc. Breaking apart in-plane vs. out-of-plane motion would have been a valid concern, certainly.

I do know that they KILLROTed the craft and that the pilot just held the sextant. So whatever method they used, I don't see how the sextant could have been aligned by anything more than eyeballing the plane, and it would have been no more accurate than the limits of "hand-and-eye" error.

Now, one way they could have done it does occur to me. I "flew a Gemini" a while back ... actually, flew this:

[ame="http://www.orbithangar.com/searchid.php?ID=1450"]Project Gemini 4.5[/ame]

In light of our work on defining the reference frame, one possible answer suggests itself -- use the real Gemini's attitude indicator in the same way the Orbit HUD is being used here. Attached are a few snaps of the addon's 8-ball in action, with Orbit HUD superimposed. Starting from a base orientation of nose pointing prograde, craft's vertical axis in orbital plane, orbit-normal vector to the pilots' left ...

attachment fg1 -- plane-aligned, yawed right 10 degrees.
att. fg2 -- yawed left 5 degrees with plane alignment error
att. fg3 -- plane-aligned, yawed right 30 degrees
att. fg4 -- yawed left 40 degrees with plane alignment error

Aligning the 8-ball's "latitude lines" at the nose of the craft with the craft's vertical axis is still the right idea, but it doesn't look as though the 8-ball could be reliably used that way, at least not directly. Orbit HUD's latitude lines aren't really true representations; rather they're straight lines which are parallel to a line tangent to the true "latitude arc" at the craft's nose, making it much easier to make this sort of judgment. Fg.3 shows that if you were to squint at the tiny portion of the latitude line near the nose, it would appear straight up and down, but with so much of the rest of the arc visible I'd have to think that alone would be too vulnerable to optical illusions.

But with that sort of orientation, something else should happen. Ignoring the display's longitude lines, which might not line up perfectly with the display's center, the rest of the 8-ball should be symmetrical about the horizontal line connecting the "9-o-clock" and "3-o-clock" marks to the edge of the indicator.

Bearing that in mind, small deviations do seem to show up at the edge of the display. For example, in fg.2 the difference between where the black/white border "equator" meets the top and the bottom edges of the display is small but readily apparent. In fg. 4 the red dot to the left should be centered relative to the "9-o-clock" mark next to it, but is not centered because of the alignment error. Again, I'm not doing anything more than guessing out loud at this point, but ... maybe that way?


SAM