Coelliptic Gemini/Apollo rendezvous

[tblaxland]

Yes, it occured to me this afternoon that when the vessel is in the correct orientation, the roll indicator on the attitude ball would be top centre and they could use that as an indicator of the orbital plane position. Here is a better image of the Apollo FDAI. See how an imaginary line from the centre of the FDAI to the is always tangent to the lines of constant yaw?

BTW, regarding the required orientation of the measurment frame, whilst I could visualise it from your description, I was having a hard time coming up with solid geometrical logic that would prove it for me. Here is what I came up with:

1. For any random target relative velocity vector, it will have one component that has an impact on the relative angular velocity measurements and one component that has no impact. The former will lie in a plane perpendicular to the relative position vector whilst the latter will lie parallel to the relative position vector.

2. The component that lies in the plane perpendicular to the relative position vector can be further broken down in to two components, the in-plane one which is perpendicular to the orbital angular momentum vector, and the out-of-plane one which is perpendicular to in-plane component.

Using cross products to determine the vectors defined by the intersection of the two planes, you get a measurement frame that aligns with the one you described. I hope that my reasoning makes sense.

 

[tblaxland]

An update on Sextant MFD: I've basically got it all working except for scenario file saving and loading and some documentation updates. I'll package up a beta release some time this week and add it to the BitBucket page: http://bitbucket.org/tblaxland/state-vector-mfd/wiki/Home

 

[Sam]

Sounds like we're working at about the same rate. On the Monte Carlo thingy, I've gone through three iterations of pseudocoding and am now most of the way through coding it. Only 30K+ lines of code so far (32768 of which are a direct rand() to Z value lookup table for the normally distributed errors; these days we've got tons of RAM so why not use it?) Family stuff is taking me away from it this weekend, but I'll probably have something ready to go in the next few days.

SAM

 

[tblaxland]

For fun, I thought I'd add the sextant angle and radar range limits in to the MFD (settable via config file). You have mentioned those limits before but do you know what the picth/yaw range limits were for the radar?

 

[Nemoricus]

This sounds like it will be a fun little challenge. I'll have to give it a go later.

 

[Sam]

For fun, I thought I'd add the sextant angle and radar range limits in to the MFD (settable via config file). You have mentioned those limits before but do you know what the picth/yaw range limits were for the radar?

One of the problems I've had trying to find out things like this is that there's just not a lot of good technical data out there, and sometimes different sources will disagree -- even two different sources from within NASA. Those numbers I cited earlier (250 nm, 25 degrees) came from two different NASA sources. But another NASA doc says that the radar acquired a lock if the target was within 180 nm and within 8.5 degrees of center, and that the angle detection increased to 25 degrees when the range decreased to <=130 nm.

But I've got another NASA source which states that Gemini 6A's first radar lock onto Gemini 7 occurred at 434 nm range. So maybe those other numbers were minimum acceptable performance figures rather than maximums.

With that said, everything I've seen implies that the maximum angle was simply the gross angle off the longitudinal axis rather than any max pitch/max yaw thing. That is, 25 degrees pitch + 0 yaw; 0 pitch/25 yaw; ~18 pitch/~18 yaw, etc. would all have the same effect.

SAM

 

[tblaxland]

It sounds like a Guassian probability distribution in angle and range would be more appropriate. I don't think I'll go to the trouble of implementing that just yet but it might be a fun experiment for later.

 

[Sam]

It sounds like a Guassian probability distribution in angle and range would be more appropriate. I don't think I'll go to the trouble of implementing that just yet but it might be a fun experiment for later.

The radar was an interesting device in its own right. Three identical spiral antennas, one for reference which was wired to be 180 degrees out of phase with the other two, and pitch and yaw antennas which were respectively below and to the left of the reference antenna. If the signal was coming from straight ahead, the signals from the pitch and reference antennas would cancel each other out. If the source was above or below center, the 180 degree phase relationship would be thrown off and the two antennas combined would receive a non-zero signal. The pitch antenna was then physically moved to restore the 180 degree phase relationship, and this movement was the data from which the pitch angle was computed and reported to the astronauts. Same with the yaw antenna for signals to the left or right of center, etc.

If you're thinking of other features to implement, here's one I'd like to see; the ability to turn off the rendezvous radar and/or the sextant, so that rendezvous could be simulated with conditions like "no radar data available," etc. According to some comments I found from Dave Scott, the actual craft had three systems upon which rendezvous navigation depended -- the inertial platform, the radar, and the guidance computer. If any one of those systems failed, they could still complete the rendezvous.

As for failures beyond a single system? or what happened if the sextant failed? -- I don't know. We don't have anything like the guidance computer (unless you could all the rest of Orbiter + add-ons that we're ignoring; e.g., Rendezvous MFD, etc.), so in a way what we're simming here is guidance computer failure and rendezvous with the platform + radar. I did see a technique Aldrin mentioned for proceeding if the radar data goes out, and tried that with the tutorial scenario. That worked well enough, at least under that particular scenario's ideal conditions, but the logic seemed solid enough to extend further. So with that we'd have rendezvous with platform only, or platform+computer if you count Windows OS's calculator app as a "computer."

I'm also thinking ahead to some possible ideas about how it might be accomplished with radar + computer but with no platform, but at this point those ideas are nothing more than "maybe if we tried something like this" kinds of things.

SAM

 

[tblaxland]

If you're thinking of other features to implement, here's one I'd like to see; the ability to turn off the rendezvous radar and/or the sextant, so that rendezvous could be simulated with conditions like "no radar data available," etc.

Beware the featuritis... lol I'll keep it in mind but I'd like to get something out the door first.

 

[pattersoncr]

Beware the featuritis... lol I'll keep it in mind but I'd like to get something out the door first.

Us project engineers refer to that as "Scope Creep."
Nothing busts the budget faster.

 

[Sam]

Us project engineers refer to that as "Scope Creep."
Nothing busts the budget faster.

LOL understood ... I've had clients try to squeeze me for all the "for free" they can get.

A little behind schedule, but the Monte Carlo programs are finished. If I can twist my arm for a moment and indulge in a little self-congratulatory patting of my own back ...

Program A computes true Lambert solutions, checks the solutions via another algorithm, and outputs parameters for each solved orbit -- direction and magnitude of TPI, time to rendezvous, delta-vee to null relative velocity at rendezvous, etc. This program is run over a bunch of target radius/delta-H combinations; for example, all orbits between target radii of 7000 km and 8000 km, with delta-H varied between 1 km and 100 km, equals 100,000 orbital solutions.

Program B takes A's output as input and computes the reference angles for the two MCCs. It also checks the straight-in nature of the final braking phase by calculating the total expected apparent motion over several intervals (65% to 80%; 80% to 90%; 90% to 95% of nominal transfer time; and from 2 km to 1 km range to target). It outputs that data as well as other data it simply "passes along" from A's output.

Program C takes the variables important enough to care about from B's output and does regression with two independent variables (target radius, delta-H), excluding cases that fall outside user-specified ranges for the two IVs. It outputs the coefficients for the best-fit linear equation -- e.g., TPI_delta_vee = C1 (tgt rad) + C2 (delta-H) + B -- along with r^2 for each.

Program D constructs target orbits with various Rincs, LPe differences, etc. relative to the active craft's orbit. It applies errors to everything along the way -- when the pilot does the TPI burn, how well the craft is aligned for measuring the MCCs, how sloppy the pilot is on making burns the right duration, etc. (In addition to the program C equations, there are 79 user-specifiable parameters specifying the "rules" of the simulation, and 49 error terms come into play.) Errors can be uncorrelated (e.g., pilots who are randomly sloppy) or correlated (e.g., pilots who tend to consistently overestimate angular distances). It takes the active craft through entire rendezvous maneuver, using the equations from program C's output which apply to the appropriate target radius and delta-H; "appropriate" meaning what the pilot thinks those parameters are, not the actual correct ones. It evaluates each simulated rendezvous against three failure criteria -- too much time elapsed, too much total delta-vee used, and too much delta-vee used in the braking phase; then spits out the success/failure status and corresponding values (e.g., DV used / expected DV), the assumed delta-H and target radius, and all the error terms.

For the morbidly curious, on a PC built around a $200 "barebone kit" including a dual core AMD Athlon 3 GHz CPU, performance is:

Program A: 340,000 orbits / minute
Program B: 6650 orbits / minute
Program C: 1.56 million cases / minute
Program D: 5500 to 12600 simulated orbits / minute, depending on how "sloppy" the simulated pilot is

To put that into context for some of the younger readers, back when I was in school, students got 300 KB each of disk space on a shared "minicomputer" for their basic needs. If you had an academic project that required more space, you could apply for it and maybe a whole megabyte would be allocated to you, but the project had better be something that led to an actual grade and approved by some faculty member. Later, our department upgraded to a "modern" Sun computer which cost about $100,000; from what I recall, doing the sort of computations program C does here took a little over a minute for a data set of 400 cases. We weren't completely in the medieval era, but did have pocket calculators (although I'm old enough to remember slide rules). But I'm sure that by the time the next generation gets gray hair, the PCs will make present-day desktop models look like clunky dinosaurs.

Well, now I can relax and let my PC do the hard work. The pilot error variables are all normally distributed; across the entire simulation the means are zero and standard deviations are generally set so that 95% of the time (+/- 2 SDs), timing errors are within +/- 0.5 second and angle errors are within +/- 0.5 degree (essentially simulating rounding to the nearest second or degree). There's no correlation between different simulated pilots, but within each pilot's performance there's an 0.5 correlation among similar errors. If anyone has any objection to those parameters, let me know, otherwise I'll go with them.

SAM

 

[pattersoncr]

Wow, I am impressed.
When I was an active duty submariner, we used a circular slide rule that we used to compute various target motion analysis parameters. It's real name was a "bearing rate computer" but wee just called them "whiz wheels."

 

[NukeET]

Wow, I am impressed.
When I was an active duty submariner, we used a circular slide rule that we used to compute various target motion analysis parameters. It's real name was a "bearing rate computer" but wee just called them "whiz wheels."

Used one while I was periscope assistant.

 

[tblaxland]

Awesome work Sam.

I've been off Sextant MFD for a few days but I should get back into it tomorrow.

 

[tblaxland]

It's Tuesday nearly everywhere in the world by now so I decided it was time to release a beta version . Get version 0.8.0 from BitBucket: http://bitbucket.org/tblaxland/sextant-mfd/downloads/

Any feedback appreciated.

EDIT: BTW, I flew a rendezvous with it and it work very nicely. My only thought was whether or not a separate timer to record the time since TI would be required. I used a stopwatch on my desk but is this a feature anyone would like?

 

[Nemoricus]

I think that a built-in timer would be helpful as it would reduce the need for people to have to keep on top of starting and stopping their own stopwatch if they need to take a break. Such a timer would also remain in sync with Orbiter during time acceleration.

 

[tblaxland]

Sextant MFD version 0.8.1 now available.

Changes:
1. Added stopwatch.
2. Fixed a bug with the range rate.
3. Updated the documentation to suit item 1 and also to note that you can have vessel class specific configuration files.
4. Added a scenario file.

I also created a worksheet that I used to fill out during the rendezvous (see attached Word document). It makes it easier for me to keep all my information organised. Sam, maybe you want to put something like it in your tutorial.

 

[Sam]

Looks great! Unfortunately, I can't seem to use it

If I include Sextant MFD in the modules tab of the launchpad but don't use it, everything's fine. But if I start up the MFD once in Orbiter, attemping to quicksave causes Orbiter to crash. Same thing if I turn on Sextant MFD then switch back to some other MFD before trying to quicksave.

It seems to be some issue with the stopwatch. The failed attempts to quicksave go only up to the "stopwatch status" line and end there. Also, when I try to use the stopwatch, hitting the start button gives a displayed time of "-21474" which doesn't change. Whether I use the stopwatch or not before trying to quicksave doesn't seem to make any difference.

I'm getting these results with the 29-Sep-06 base version, with no other addons and no options or other modules activated beyond what's absolutely necessary to test it. But it might be my PC. It's running Windows XP Media Center edition, kind of a weird mutation of XP Pro. SP2 is installed. When I first installed Orbiter it worked great, but later I wiped and reinstalled the OS. When I did that I had a devil of a time getting Orbiter to work at all and had to download some DLLs -- msvcp71.dll and msvcr71.dll. I'm guessing that it's something to do with one of those? I went looking around on the forum and found a thread addressing this issue which said to install those as well as msvcrtd.dll in the Orbiter root directory. I had the other two but not this one already installed, tried adding msvcrtd.dll but no change in results.

Also tried it with the same Orbiter version + Sextant MFD v0.80 and got the same results for attempted quicksaves, except the quicksave files go up to "timer status."

I agree that the stopwatch is a must-have. When I wrote the tutorial, I listed it as optional equipment but I wasn't thinking of time acceleration; once you get tired of doing the whole rendezvous at 1X, the only alternative without a built-in stopwatch is to write the time down from the top right display and work from that.

Meanwhile ... I'm simming orbits over here and am uncovering problems with the general procedure. It turns out that the it's more sensitive to Rinc between the active and target craft than I'd hoped. I don't mean that huge RIncs cause it to fail, I'm talking about small ones (<=0.01 degree). There's an off-angle cost built into the procedure which I'd hoped would be tiny for Orbiter, since Align Planes MFD can get rid of 99.999% of RInc, but apparently not. The choice of two MCCs was almost arbitrary (it looks like NASA probably did it that way), and putting them at 10 and 20 minutes was completely arbitrary (without braking, the rendezvous trajectory takes about 30 minutes in LEO). Moving the MCCs around helps the RInc situation some, but not enough. So, gotta figure out some way to deal with that. I'm still hoping to keep this all as simple as possible, but by the time this is all done I think the next tutorial version might include a couple of worksheets, etc.

SAM

========
[aborted quicksave file -- from Orbiter's included "checklist 1" scenario]
BEGIN_DESC
Orbiter saved state at T = 13
END_DESC

BEGIN_ENVIRONMENT
System Sol
Date MJD 51983.5620812188
Help Checklist1,Checklist1
END_ENVIRONMENT

BEGIN_FOCUS
Ship GL-01
END_FOCUS

BEGIN_CAMERA
TARGET GL-01
MODE Cockpit
FOV 50.00
END_CAMERA

BEGIN_HUD
TYPE Surface
END_HUD

BEGIN_MFD Left
TYPE Surface
SPDMODE 1
END_MFD

BEGIN_MFD Right
TYPE User
MODE Sextant
TARGET SH-03
REF Earth
STOPWATCH_STATUS 0
[file ends here]

---------- Post added at 05:37 PM ---------- Previous post was at 05:17 PM ----------

OK, it gets better. I tried your included scenario file and was able to quicksave and reload from that. The difference was that in that SCN file, Sextant MFD is already loaded. I edited the scenario file I was working with and manually put Sextant MFD in so that the sim started with that MFD running, and quicksaves now work.

SAM

 

[tblaxland]

OK, it gets better. I tried your included scenario file and was able to quicksave and reload from that. The difference was that in that SCN file, Sextant MFD is already loaded. I edited the scenario file I was working with and manually put Sextant MFD in so that the sim started with that MFD running, and quicksaves now work.

Thanks for the feedback. Can you post the scenario file that was causing you the problems? I can't seem to replicate the bug here.

 

[Sam]

The zip file has the SCNs in it, which are just different permutations of trying
to turn the MFD on then quicksave; turn the MFD on then off again before quicksave; etc.

> I can't seem to replicate the bug here.

Yeah, my PC is weird. I saved a few bucks by getting XP Media Center instead of full XP Pro and have regretted it ever since. :compbash: I wouldn't be surprised at all if it was just this PC.

SAM