Coelliptic Gemini/Apollo rendezvous

[Sam]

Continued from thread "Interesting Interplanetary Flights You've Made," since this isn't interplanetary.

Lately I've been doing some stuff with orbital rendezvous, without the God-in-the-box showing where the satellite is; no F9, Docking HUD/MFD, etc. Basically using Orbit MFD's numbers to get a rough idea of where in the visual field the satellite is, finding it, and eyeballing your way in. <snyp>

That's how the Gemini crews did it. I'd like to have some of their notes.

Same here. I wasn't particularly shooting to duplicate their methods, just the result, but it would be nice to see how the pros did it. I did already know that they came at the target from behind and below, so I did it that way. It's pretty straightforward to do it with what Glynn Lunney called "direct ascent" (see below), as long as you have Orbit MFD's numbers for an initial fix, Sync Orbit MFD to monitor the range to target, and Surface HUD to monitor the approach angle. (Telescope MFD helps.) But that's still a little more God-in-the-box than what I'd like.

I got intrigued and did some more digging on the Internet yesterday and came up with a few things about Gemini rendezvous. One interesting resource is "Summary of Gemini Rendezvous Experience," a paper Glynn Lunney wrote for the AIAA:

http://www.klabs.org/history/papers/lunney_gemini_rendezvous.pdf

He describes three general rendezvous methods:

1) Direct ascent. Start from behind and below, simply "fly up to" the target, and stay below and behind the target all the way through the rendezvous.

2) Tangential. Set your apoapse at the target altitude, then use a series of prograde burns at successive apoapses to fine-tune as you close the distance between youiself and the target. Again, you're always behind the target this way.

3) Coelliptic. Start from behind and below. During the terminal approach phase, come up to the target's altitude, passing under the target and rendezvousing from **in front** of the target.

Lunney gives graphs of all three of these on page 2 of his paper (orbital motion is from right to left). Turns out that coelliptic is how Gemini and much of Apollo did it. I don't NASA's done it that way since the middle of Apollo, but I think I see why they were doing it that way -- it makes the star sightings simpler -- and I suspect the Shuttle astronauts are still trained in this in case they've gotta do a Gemini 12 style "bare bones" rendezvous.

Anyway, the more I look at this, the curiouser and curiouser I get. I'm gonna play around with some data and (1) see if my suspicions are correct, and if so (2) try to come up with some reasonably realistic Orbiter scenarios that could be done in a bare bones kind of way. Meanwhile, if anyone's already worked on this, or knows of other technical resources that could help me out, I'd appreciate hearing about it. Will check back in later.

SAM

 

[kuddel]

Hi Sam,

I can only report one "technical resource":
[ame="http://www.amazon.com/dp/1894959078"]Amazon.com: How NASA Learned to Fly in Space: An Exciting Account of the Gemini Missions: Apogee Books Space Series 46: David M. Harland: Books[/ame]

This book is really nice in explaining the different challenges of each Gemini Mission.
Although it is not a really official "technical resource", it has lots of diagrams, tables and detailed stuff in it.

/Kuddel

 

[Sam]

This book is really nice in explaining the different challenges of each Gemini Mission.
Although it is not a really official "technical resource", it has lots of diagrams, tables and detailed stuff in it.

Thanks! My budget's kinda tight at the moment, though, so I'm hoping to get through this with only freebies unless I absolutely can't. What I'd really like to see is an example of the tables the astronauts used for a sextant-only rendezvous; does it have anything like that?

SAM

 

[Sam]

I found Aldrin's doctoral dissertation and a few other things, and between those and the orbital stats I already had, I think I've put together a scheme to simulate the Gemini rendezvous trajectory. The results seem to line up with the real thing on several levels. The target-relative trajectory goes to a straight line in the terminal braking phase; the craft ends up approaching the target from below and in front, with the Sun at the pilot's back (lighting up the target nicely); etc. I've run this several times with slightly different starting orbits, and my total delta-vees are consistently around 50 m/s for the whole thing, which is about what the Gemini pilots used.

No God-in-the-box; Orbit and Surface HUDs are used to eyeball angles, and Docking MFD is used for range and range rate; information the Gemini pilots had directly available and used during rendezvouses. The technique is pretty simple, and the learning curve is mainly getting used to the workflow cycle -- measure an angle, compute the MCC, do the MCC, then repeat. No addons required, and takes a little under an hour to do.

Doing it is one of those "oh, now I get it" kind of things, but it's surprisingly easy. It does take some explaining, though. I've written up the procedure and will put it into a PDF and post it on Orbit Hanger, but I'd appreciate a few beta readers/testers. PM me or let me know here if you're interested.

SAM

 

[Sam]

OK, it's up on Orbit Hangar. You can see the summary and prerequisites in the OH section of this board. Enjoy!

[ame="http://www.orbithangar.com/searchid.php?ID=4127"]Gemini semi-optical rendezvous tutorial (v 0.3)[/ame]

SAM

 

[flying coffin]

This is fascinating stuff! After you get used to it, you can just eyeball the
corrections and get a perfect rendezvous every time! I wonder if the TI burn
can be generalized for other scenarios.

I read Aldrin's dissertation, (skimmed the math parts) and he seems to recommend a pitch down angle for the TI burn of 20 degrees, whereas in your
scenario, your pitchdown is a bit less than 10 degrees. I could be reading this
wrong, however.

I remember rendezvous being my first big hurdle to learning orbiter.

Thanks a bunch!

 

[tblaxland]

OK, it's up on Orbit Hangar. You can see the summary and prerequisites in the OH section of this board. Enjoy!

I haven't tried the actual rendezvous yet but I have read your tutorial and I must say it is a fascinating read. You have done a great job there - easy to read, well balanced content, etc. Thank you for the work you put into this.

 

[Sam]

> I haven't tried the actual rendezvous yet but I have read your tutorial and I must say it is a fascinating read. You have done a great job there - easy to read, well balanced content, etc. Thank you for the work you put into this.

You're quite welcome, and I appreciate the kind words! And the implied beer. Now go forth and do the rendezvous!

> After you get used to it, you can just eyeball the corrections and get a perfect rendezvous every time!

Yeah, the biggest part of the learning curve seems to be getting used to the work flow cycle -- measure drift, compute MCC, do MCC, rinse and repeat. What flabbergasts me about this is just how much of a tolerance for error the overall scheme has! When I first looked into this, I thought I'd have to work up some sort of scaled printout of a ruler that I could tape to the monitor for the angle measurements. I never imagined that it was possible to just eyeball the angles and do it.

> I read Aldrin's dissertation, (skimmed the math parts) and he seems to recommend a pitch down angle for the TI burn of 20 degrees, whereas in your
scenario, your pitchdown is a bit less than 10 degrees. I could be reading this
wrong, however.

I don't remember what part you're referring to; unlike your more careful look, I did far more "skimming" than "reading." I'm sure you're right. My goal was to replicate that specific NASA trajectory and the straight-in result Armstrong described in section 3.2, so I considered that trajectory's parameters (130 degrees, 26 degrees, 15 miles) to be carved in stone and pretty much only "consulted Aldrin for advice" on how to calculate the MCCs. Whatever Aldrin considered desirable in his dissertation, ~8.5 degrees is what the initial pitch-down angle worked out to be for a direct trajectory to rendezvous, so I used that.

I do remember that Aldrin frequently placed his ideas into "real world" contexts (Gemini plans, simulation experiments that had been done in planetariums, etc.) I imagine that a legitimate concern would be optimal visibility out the right side Gemini window for the pilot to see the target and have enough room around it for plenty of stars to sight the target against. Maybe he was talking about something like that?

The pitch angle issue is worth mentioning, because I suspect that the real astronauts used some non-zero pitch angle when measuing and making their MCCs to aid visibility. I don't know what that angle might have been, and there was no way to simulate that sort of thing in the tutorial because Orbiter doesn't have a separate sextant; its main window is the "sextant." But to the extent they pitched away, they would have used more delta-vee to accomplish the same effect, which means my Appendix C (compare sim results to real astronaut performance) isn't quite a direct comparison. (As if a Delta Glider is a fair comparison in general to a real Gemini!) So making that sort of comparison between the delta-vees used in this simulation and in the real flights is slightly unfair to Lovell, Stafford, Young, Conrad, etc.

> I wonder if the TI burn can be generalized for other scenarios.

If you're going to try different variations on this technique, read footnote 8 in the tutorial if you haven't seen it already -- the MCC formula in the main text only works if the DG's mass is specifically set a certain way. The footnote gives the actual formula which isn't much more complicated, but I set things that way in the main text and scenario so I could focus on ideas, not math.

After some email discussions with another user yesterday, I went ahead and tried the same thing with ISS. If you want to try that, the scenario parameters I ended up with are down below. I used the "checklist 2, ISS to Mir" scenario included with Orbiter, undocked "GL-01," then quicksaved and put the DG where it needed to be. I didn't recalculate anything for the technique, nor did I adjust the times in Appendix A (see below), I just used the initial burn and MCC parameters in the tutorial. Everything worked fine.

I've run the numbers and it looks like if the 130 degree transfer angle is held constant, the initial burn parameters are far less sensitive to variations in target radius than they are to variations in delta-height (24 km) and initial elevation (26 degrees) -- hundreds to tens of thousands times less sensitive.

Maybe the biggest concern in that situation is that the timing numbers in Appendix A get thrown off. The transfer time is obviously about a third of the target's orbital period. For ISS that means that by the end of the transfer, the times in Appendix A are roughly thirty seconds off. Now that's less than a 2% error and it's not worrying about for ISS; you're already getting far bigger errors because of the "looks about right" standard for measuring angles. But my suspicions are that as this technique is applied to targets with even higher radii, adjusting the times in Appendix A might be the first correction that has to be made.

The tutorial's scenario starts with Gemini already in coelliptic orbit with Agena; Mission Control has done all the work to put you there. One thing I haven't looked at, other than a couple of quick tries in Orbiter, is how to get there with only Orbiter's default instruments. Having non-spherical gravity turned on doesn't seem to make the actual rendezvous any harder once you're in coelliptic orbit, but it makes it impossible to get into that orbit! ... :compbash: ... and I suspect that even with that turned off, perturbation from the Sun and Moon still make it a challenge. I'll have to look at that further.

SAM

(starting points for rendezvous with ISS; use same angles, etc. as in tutorial)

GL-01:
RPOS 6547105.46 -1137763.31 -947493.49
RVEL -940.92 -7313.59 2246.48
PRPLEVEL 0:0.4569 1:0.500 // to make the MCC formula and Appendix B work

ISS
RPOS 6563146.75 -1197140.61 -933843.27
RVEL -1004.172 -7288.987 2251.799

 

[flying coffin]

I also just tried (before I read your post) a shuttle to ISS rendesvous,
starting with a coplanar orbit with a delta height of 20km. I used the exact
same angles for the TI burn, and for the magnitude I burned until Apa was
4km higher than ISS Apa, which is what I observed happening at the end
of the TI in your gemini scenario. I used the 4.4 degree drift value for the
initial MCC and pretty much eyeballed the corrections from there.

This is where I ended up:

It doesn't get any better than that! No math needed at all!
(well, you do need addition... 365.7 + 4 = 370 ):lol:

and subtraction to get to the 20k delta height, but no fancy mulplitication
or diverision

Did you see the dedication on Aldrin's paper? It's priceless!

"In the hopes that this work may in some way contribute to their
exploration of space, this is dedicated to the crew members of this
country's present and future manned space programs. If only I could join
them in their exciting endeavours!"

Little did he know.....

 

[dougkeenan]

Thanks for sharing this Sam. Neat technique!

 

[Sam]

> Thanks for sharing this Sam. Neat technique!

Thanks, Doug! Have you tried it yet?

> Did you see the dedication on Aldrin's paper? It's priceless!

Yeah, although I also got a big kick out of this one (p.35):

"[M]uch as the author would like to design the [rendezvous optical sight] for patent purposes, he had dealt mainly with what it should be capable of doing and pointed out only briefly how this might be accomplished."

IOW, "I'd like to get into the space program, but if that doesn't happen I've got a Plan B; design the equipment and make a bloody fortune." :lol:

> I also just tried (before I read your post) a shuttle to ISS rendesvous, starting with a coplanar orbit with a delta height of 20km. [...] It doesn't get any better than that!

You're braver than I am; my plan so far has been "vary the radius, but don't vary the other parameters" including the 24 km delta-height, and gradually move away from that and see what causes things to fall apart. But after reading your post I decided to go for broke and put together a somewhat bad situation and see how things worked.

The tutorial's data is designed for target SMa=6661 km; delta-H=24 km and constant; LPe difference=0; RInc=0. I set up this situation -- target SMa=6735 km (ISS); chaser SMa=6706 km; LPE diff > 0; RInc=0.09.

Then to make things worse, I "broke" the rendezvous radar (ignored Docking MFD). I used one of Buzz's ideas to deal with that -- use a linear function of time as an estimate of range until that estimate drops to the nominal braking distance, then hold the estimate there. For the tutorial data, that means estd_range(km) = (47.4 - 1.66 * time(mins)), or 2 km, whichever is greater. And to make things worse still, I deliberately mis-aimed the initial burn by burning directly at the target craft instead of the prescribed ~8 degrees down.

The first time I tried it, PeRs differed by 24 km, ApRs differed by 34 km, and LPes were 23 degrees apart. That only worked out halfway. I ended up on a straight-in path when I should have, but was moving away from the target at about 6 m/s instead of going toward it.

For the second trial, I left everything else alone but adjusted the chaser's PeR and ApR so that both were 29 km less than the corresponding target craft parameters. In doing that I also ended up reducing the LPe difference to about 11 degrees.

And ... back to business as usual! Fifty minutes from initial burn to docking; straight in path when close to the target; ~50 m/s delta-vee used; no problems -- kinda scary how predictable this can get! Other than having to do MCCs horizontally as well as vertically (I ended up making some +/- 6 degree, 1 degree increment paper rulers and taping to the monitor edges; the g/f thinks I've got nuts :lol: ), the only difference was that all the pitching and yawing with the nose out of plane caused some rolling away from having the orbital plane straight up and down, so I had to realign vertical (Orbit HUD lines) before measurements and before MCCs.

SAM

 

[dougkeenan]

> Thanks for sharing this Sam. Neat technique!

Thanks, Doug! Have you tried it yet?

Yep, did so right away. I didn't bother with a stopwatch, just burned at sim=300 and every 100 sec or so after 700s. Your paper is fun to read and clear on procedure. That's sweet to come up in the sunrise!

BTW, is Aldrin's dissertation online? I'm still reading the Lunney paper but also want to see what Dr. Rendezvous had to say about it.

 

[flying coffin]

BTW, is Aldrin's dissertation online? I'm still reading the Lunney paper but also want to see what Dr. Rendezvous had to say about it.

Yes it is.

http://dspace.mit.edu/handle/1721.1/12652

 

[pattersoncr]

Sam,
I was very intrigued by your tutorial and wanted to expand it a little bit.
I wanted an easy method to compute required MCC dV (rather than burn time) so that this method could be used with vessels other than a DG at a specific weight. I played with the dV formula (pg 38) and was somewhat surprised to find that if you make the (not too rough) assumption of 1 radian = 60 deg, the formula simplifies to:
dV = (angle error) * (range in km) / 7.2 for 2 min observations
dV = (angle error) * (range in km) / 3.6 for 1 min observations

My intention was to use your technique, this formula, and the IMFD dV program to perform the rendezvous. (IMFD dV allows you to monitor dV along all three axes.) IMFD didn't work out so I used BurnTimeCalcMFD instead. BTC displays total available dV which count's down as you thrust.
For my own reference, I put together a reference sheet with the expected drift angles and MCC dV values using a more precise version of the above formula (Table 1). Also on my reference sheet is the table you included in Appendix A (time vs. angle) in my sheet, this is Table 2. Notice that I included multiple copies of this table (2a, 2b, etc). My thought is that similar angle tables could be computed for half a dozen or so other initial conditions.
After I made my reference sheet, it occurred to me that what you really need instead of a table of angle vs. time, is angular rate vs. time.
As some background to my thoughts on this, there are several different “visions” of the future floating around out there. On of my favorite collections of add-ons is Greg Burtch’s stuff. If you read his documentation, he envisions a future with very little manual flying done by human pilots. Orbital operations are highly automated, often without a human pilot on board. One of my other favorites is the XR series. These craft represent a very different vision with humans doing much more hands on flying. In my view, simple effective techniques like this would factor heavily into that type of future.

 

[Sam]

Hi Chuck,

> if you make the (not too rough) assumption of 1 radian = 60 deg

I think that sort of approximation is perfectly justifiable, considering the error already present in "eyeball" angle measurements. I've been meaning to look around to see if there's a "Sextant MFD" out there somewhere.

> IMFD didn't work out so I used BurnTimeCalcMFD instead. BTC displays total available dV which count's down as you thrust.

Ah, ok! ... I had thought of trying something myself with BTC but just assumed I'd have to point the nose up, left, etc. to make the burns, so I didn't think of looking at it further. But that certainly works.

> My thought is that similar angle tables could be computed for half a dozen or so other initial conditions.

From what I've seen so far of the various values that come into play, the relationships seem to be roughly linear with some curvature. That is, the smaller an interval they're examined over, the closer they come to straight line relationships. So one thing that occurs to me is that if you had a few tables like that, you could probably also have simple equations associated with each table that might specify each variable's behavior near that particular tables conditions. For example, the table for radius 6700 km might say something like "delta-vee magnitude = 9 m/s; add 0.1 m/s for every km radius above 6700 km" whereas the 6750 km table might give a value and say to add 0.08 m/s for every km radius above 6750, etc. (these values aren't the real numbers, obviously). Also similar linear relationships for initial delta-vee direction; etc.

That way a small number of tables could pretty accurately cover a wide variety of starting conditions. I haven't looked specifically at the angle data and how it varies as other variables are tweaked, but it wouldn't surprise me if it followed similar curvilinear patterns.

> After I made my reference sheet, it occurred to me that what you really need instead of a table of angle vs. time, is angular rate vs. time.

Sure. That would be the ideal basis for the MCCs. And it would be trivial to compute the predicted values. If you could somehow measure the instantaneous angular rate, say at T+10:00, and compare that directly to a predicted value for T+10:00, I suspect that the MCCs would be that much more accurate.

But I'm a little confused as to how you'd use that information in Orbiter? Every way I can think of to measure rate of apparent motion comes back to some variation of "note position P1 at time T1, note position P2 at time T2, then compute (P2-P1)/(T2-T1)," which gets you the mean angular rate for that measurement interval but not the instantaneous angular rate for any specific time ... and seems to put you right back to some sort of angle vs. time data.

I've still got all the data from the reference orbits (Gemini's position and velocity, and Agena's position and velocity, at T+30s, 60s, 90s, etc.); also the code to generate that data. Or it would be a simple matter to crank out the expected immediate angular rates for T+30, T+60, etc. If any of that would be helpful to you, just let me know, you're welcome to it.

SAM

 

[pattersoncr]

Sam,
With regard to rate measurements, you would measure them the same way you had already laid out: put the nose on the target at say time 7:00 then note position at time 9:00. What I'm saying is that when using this technique, rather than comparing expected angle at time 7:00 and time 9:00 to find the expected drift rate, you could have the table set up to give expected drift rate at time 8:00.
Rather than subtracting the 7:00 & 9:00 values, you could just read the expected drift rate directly. It could list values in deg/min or deg/(2min).

 

[Sam]

Chuck,

OK, I think I see what you're getting at. I can see two possible ways to go about doing it.

One way would be to just state directly the expected drift for that interval. For example, the table would state 4.4, 4.3, 4.2, 4.1 for the intervals starting at 7:00, 7:30, 8:00 and 8:30, and a pilot timing the drift from 7:30 to 9:30 could just read 4.3 from the table instead of having to subtract 23.2-18.9.

That would relieve the pilot from doing the subtraction, but it seems to me that the price you pay is that the table is now hard-coded to that particuclar measurement interval. Two minutes seems to be a good interval to me, but that's nothing more than my personal preference. For example, suppose the pilot prefers a 60 second measurement, or a 2:30 measurement? In that case things get more awkward, and the pilot's workload is no lighter; instead of doing a subtraction step, he or she now has to do a multiplication and/or division step.

Another way would be to specify the instantaneous rate of apparent motion at each time and let the pilot compute the expected drift for any interval from that. For example, the pilot timing from 19:00 to 21:00 might read the instantaneous rate for 8:30, which is 0.036 degs/sec = 2.14 degs/min (see attached file). The expected drift for the 7:30-9:30 interval then becomes 2 * 2.14 degs = 4.28 degrees,

The thing that bothers me about that is a point that I'll admit is pedantic as far as how such a table would be actually used. The rate of apparent motion is not constant, nor is it even a linear function with regard to time, but the pilot would have to treat it as a constant value for any calculation that could be done in real time. What the pilot needs at that point is the predicted value of the non-linear function F(t). With an time*rate computation, it seems to me that the pilot would have to compute (t * table_value) to approximate that predicted value ... but as it stands now, the pilot can already get the predicted value of F(t) by subtracting angle(t2) - angle(t1).

Provided the measurement is kept short I don't think using a rate*time approximation is comparing apples to oranges, but I can't help thinking that it is comparing oranges to tangelos. Now, I wouldn't mind doing it that way at all if it made the procedure significantly easier, but as it stands that doesn't look to me to be the case; with the table's present form the pilot only has to do a single subtraction, and it can't get much easier than that.

I do think your point is an excellent one as far as the text goes. The "Ground school" chapter has nothing at all explaining how rate of apparent motion figures into the method, and in the "Tutorial" chapter I didn't say much more than "just take my word for it, this works." I'm accumulating a list of things to revise for the next version, and that's now on the list.

Regarding Appendix A, one user emailed me that it's a little clumsy to read as it stands. It's too easy to accidentally read the angle value for 7:30 instead of 7:00, for example. That's another change I'm going to make.

I went ahead and calculated instantanous apparent motion numbers for the tutorial's rendezvous trajectory and wrote all the data (including predicted range, range rate, etc.) to a CSV file, so if you or anyone else wants to use that data, feel free.

> [H]e envisions a future with very little manual flying done by human pilots. Orbital operations are highly automated, often without a human pilot on board. One of my other favorites is the XR series. These craft represent a very different vision with humans doing much more hands on flying.

I haven't given much thought to what the actual future might hold, but as far as Orbiter goes I tend to bounce back and forth between the two extremes. I'll do everything by autopilots for a while, then I'll feel like I'm somehow cheating and go to the other extreme of doing everything by hand. Right now "low tech" things have got my attention. As for this scheme of semi-optical rendezvous, I guess what I'm "working on" right now is finding the outside of the envelope for initial orbit conditions, to make the scheme more usable in general.

Thanks for the comments!

SAM

 

[pattersoncr]

But Sam, the way you are using the table now, what you are measuring is the average angular rate over a two minute period.
Why not just have the table give you that value directly?
I would set the table up to display predicted angular rate every thirty seconds.
For each measurement, pick the displayed value that is closest to the middle of your measurement period.
I don't think the raw angle values you have now are useful. i.e. the target should be at 24.2degrees at 10:00 but that number isn't useful since you don't maintain the initial inertial attitude and there is no way (with standard orbiter instrumentation) to determine an inertial attitude/angle.
But of course, this is your product. Implement it however you want.

 

[Sam]

Chuck, I welcome the critique and have no aversion to changing to data format if I'm shown a better way to do it. I set it up that way for a number of reasons, but the most important reason is pilot workflow. The procedure has to be do-able in real time. Now, suppose the pilot uses a two minute measurement. There's nothing about the technique that makes 2:00 mandatory or preferable to some other interval, and I don't want the data in App. A to be hard-coded to a two-minute interval in any way. But 2:00 is what the tutorial uses, so let's go with that. Usually, I can get the MCC calc'd and burned within a minute after the end of the measurement. So using my performance as a "reasonable average," that means a three minute work flow cycle.

In order for this to be performable in real time, to my way of thinking the pilot should be able to perform the calculations three times in that cycle at a brisk but comfortable pace. Once to find the answer; a second time to check the first result; and a third time to settle the question if the first and second answers don't agree. That's why I'm nitpicking about even adding a single addition operation or some similar change. Given those conditions, I consider adding even a single arithmetic step to that workflow cycle to be a real cost, and I'm very reluctant to make such a change unless there's some real benefit that outweighs that cost.

Try as I might, I just don't see how what you propose results in fewer arithmetic steps. At best, it seems to produce computations that are no more but no less complex than the existing computations, but only if the two minute (or some other) timing interval is hard-coded into the table. I don't see a way to do what you propose and keep the table free of a hard-coded interval without either (a) requiring more arithmetic steps, (b) producing a less accurate result, or (c) both. Maybe I'm missing something, but I just don't see it.

You correctly point out that the main variable driving the MCC calculation is average angular rate. (Well, actually it's the average error of the angular rate.) But there's a distinction that needs to be made here. The pilot doesn't measure the average; he or she measures total angular drift (or total angular error) over the time interval, then calculates the average from that. That's may seem a pedantic distinction, but in the context of my "operational" concern I don't think it's trivial. The pilot measures total drift over the time interval, and the table directly relates that measurement to expected total drift. It seems to me that's more straightforward and less prone to error by the pilot in real time than having the table present angular rate. As it stands, the pilot measures variable X, and the table tells what X -- not X/T -- should have been.

Your objection (if I understand it correctly) that the numbers in App. A aren't useful because they don't relate directly to some zero point, I think, misses the idea. The numbers are only relative to each other, not to some absolute standard. Considering them against some fixed zero point, presumably the initial apparent position of the target at the rendezvous burn, is not only unnecessary in the technique but would be a mistake, which is why in the tutorial I specificially cautioned against keeping a "total accumulated error" count or doing anything else like that. At best, doing that results in wasted fuel, but it's likely that doing it that way would result in missing the target altogether. But just because the numbers aren't used as a direct comparison to some zero point doesn't mean they're not useful. If on a 90 F summer day you walk indoors to your 70 F home, you don't have to compare against your 0 F freezer to know that you're twenty degrees cooler.

To give a more formal mathematical defense of the table numbers, what they are is the integrals of expected angular motion over time. They weren't calculated that way, but that's what they are, and subtracting the angles for 12 min. and 10 min. to get the expected total motion is computing the definite integral from 10 to 12 minutes by subtracting F(12 min) - F(10 min). In doing that, the zero point (the constant of integration) drops out. I suppose the zero point could be moved, maybe to the expected angular position of the target at the beginning of the braking phase, and that wouldn't make any difference at all in the technique -- but since the pilot isn't supposed to use the zero point at all, I don't think it adds any benefit to do that.

SAM

 

[flying coffin]

Sam,

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. (ok. call it 2.2 degrees per minute if you don't want a specific time interval). This doesn't change much in the next several minutes. The thing is, that doing the burns perpendicular
to the line of sight, in the orbital plane, self corrects existing error conditions.

I'm sure this works for any reasonable LEO, and initial delta H.

I lost the toolbag with the chart and my slide rule during my last EVA.
The flight computer has had a BSOD, and I think it's running windows 2000
on a TRS-80, so it will never get rebooted in time. :lol:

All I've got is the range, range rate, and HUD. After the initial MCC, I look at the drift again using 4.4/2min and see if I over corrected or undercorrected. (sorry, I was asleep in class when they talked about the
thrust ratings of the RCS system)

The range and range rate should look reasonable. I know 3 more things.
1. The target will drift upwards on the orbit HUD slowly and should be
between 100 degrees and 144 degrees at 2km range.
2. The target drift against the stellar background will slow down eventually, and be pretty much null at orbit HUD andgle of 100 degrees or so.
3. the range rate will decrease over time, so my arrival time is not a linear
function of range.

From there, I just wait, look at how the drift is going on the oribt hud vs range, and if it looks like things may be going a little south, I'll do a correction to slow, or speed up the drift against the orbit hud.

Last time I did this with your scenario and looked at the remaining RCS fuel
I had 384kg of fuel left, as opposed to your 380.

The formulas and charts are useful for understanding why it works, but
as far as actually performing the procedure, they don't seem to be needed.

I'm pretty sure I could also stop the drift at 90 degrees, if the range is reasonable, and do a straight R-Bar approach.