Meadville Space Center
Welcome, Guest. Please login or register.
May 19, 2013, 10:55:13 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
20010 Posts in 1929 Topics by 2250 Members
Latest Member: mikegk
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  RDV SPREADSHEET
« previous next »
Pages: 1 2 [3] 4 Print
Author Topic: RDV SPREADSHEET  (Read 2583 times)
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #30 on: August 16, 2011, 11:57:31 AM »

Thanks Christophe for the new excel!  Thumbs Up

No problem, it's my pleasure.

But another point: I don't know if the insertion orbit in Apollo 7 is really correct because I never found data about neither the longitude of the ascending node nor the argument of periapsis of the insertion orbit (or any orbit later in the mission), so if someone knows a reference... Happy

That's the problem. There's a terribly lack of information about that kind of data.
The only way to get the answer is to compute from some reports doc which give the velocity components at insertion. Knowing the Pe and Ap at insertion, the vertical velocity (Vz) should give the excentric anomaly and then the true anomaly. Then, knowing the position at insertion the longitude of periapsis should be calculated to.
In the same way, knowing the exact Inc at insertion (this could be found in mission reports or "Apollo by the numbers" pdf) and angle of path the LAN can be defined.

But I don't know if such a computing would be very accurate, taking into account all the perturbations, dispersion etc.
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #31 on: August 16, 2011, 02:04:01 PM »

I think we may be going about this wrong. AFAIK, the only burns that needed to be manually computed were insertion/NCC1, CSI/NCC2, and CDH/NSR. All that really needs doing is placing the spacecraft into such a position (while remain authentic to the flight path as best as possible) to allow the AGC to take over for TPI onwards. So I'm wondering, is there a way to do the burns with post-phasing state vectors and just take it from pre-NCC1 to CDH?
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #32 on: August 16, 2011, 02:51:05 PM »

I think we may be going about this wrong. AFAIK, the only burns that needed to be manually computed were insertion/NCC1, CSI/NCC2, and CDH/NSR. All that really needs doing is placing the spacecraft into such a position (while remain authentic to the flight path as best as possible) to allow the AGC to take over for TPI onwards. So I'm wondering, is there a way to do the burns with post-phasing state vectors and just take it from pre-NCC1 to CDH?

I think that the CSI and CDH were manually computed (I guess you mean by the ground) because the AGC version of Apollo 7 was  sundisk instead of the colossus we use in vAGC/projectApollo. And I believe sundisk was not able of P32/33 (not sure of the exact program number...) to compute CSI CDH.
Normally, our AGC should do that...

After all, RDV spredsheet only must compute the CSI/CDH/TPI by itself in order to offer a proper phasing solution to establish the proper geometry. If the solution is valid, from CSI point we don't need it anymore and its CSI/CDH/TPI solutions are for information only or at least as a backup.
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #33 on: August 16, 2011, 04:13:38 PM »

Quote
I think that the CSI and CDH were manually computed (I guess you mean by the ground) because the AGC version of Apollo 7 was  sundisk instead of the colossus we use in vAGC/projectApollo.
MSFN always computed its own solution for all maneuvers except TPI, which was too time critical. All four solutions (LGC,CMC,AGS,MSFN) for every burn were compared, with the LGC solution being the one to be taken when it was reasonable.
Interestingly, the first CMC that was capable of computing CSI/CDH flew with Apollo 10. Yes, this means that the Apollo 9 CMC (and the version we use for Apollo 7/8) was not able to 'rescue' a stranded LM completely by itself(!). Obviously this didn't bother NASA. Maybe it was enough to have the AGS as 'first line' backup and the ground solution as second in earth orbit.
One thing with the burntabs: I've played around a little bit and one interesting thing is that your timing is bad someway. When I do my phasing burn 14 min earlier, I can use the dV's from the tab to get the desired orbit. But at the desired time, I need significantly more dV for that.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #34 on: August 16, 2011, 04:58:16 PM »

Yes, this means that the Apollo 9 CMC (and the version we use for Apollo 7/8) was not able to 'rescue' a stranded LM completely by itself(!). Obviously this didn't bother NASA. Maybe it was enough to have the AGS as 'first line' backup and the ground solution as second in earth orbit.

You’re right. I checked. Artemis got P32/P33 but colossus didn’t.
For rescue, the procedure was to use the burn data computed by the LM and transmitted to CSM. The CSM then used it with sign inversion for a rendezvous “from above” and, amazingly that worked!
One interested thing would be trying that with RDV. It is capable of rendezvous from above too.

One thing with the burntabs: I've played around a little bit and one interesting thing is that your timing is bad someway. When I do my phasing burn 14 min earlier, I can use the dV's from the tab to get the desired orbit. But at the desired time, I need significantly more dV for that.

I suspect non spherical gravity field to be responsible of that.
I was planned to be at work for 2 days but that was cancelled so I spent most of the afternoon trying to figure out how to include the perturbation in RDV.
The problem is to do that in an acceptable way which saves the user from a wait for long and boring iterations. 
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #35 on: August 16, 2011, 05:34:40 PM »

Quote
The CSM then used it with sign inversion for a rendezvous “from above” and, amazingly that worked!
Not quite. The AGC had different programs for that: P32 was 'CSI targeting -this vehicle active', P72 was 'CSI targeting -other vehicle active', analogous to that were P33/P73, P34/P74 and P35/P75. Although 'different program' is somewhat overstated: at startup, the program just set or reseted the AVFLAG and then jumped to the common code for both programs -that saved fixed memory. Wink
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #36 on: August 16, 2011, 05:59:05 PM »

I think we may be going about this wrong. AFAIK, the only burns that needed to be manually computed were insertion/NCC1, CSI/NCC2, and CDH/NSR. All that really needs doing is placing the spacecraft into such a position (while remain authentic to the flight path as best as possible) to allow the AGC to take over for TPI onwards. So I'm wondering, is there a way to do the burns with post-phasing state vectors and just take it from pre-NCC1 to CDH?

I think that the CSI and CDH were manually computed (I guess you mean by the ground) because the AGC version of Apollo 7 was  sundisk instead of the colossus we use in vAGC/projectApollo. And I believe sundisk was not able of P32/33 (not sure of the exact program number...) to compute CSI CDH.
Normally, our AGC should do that...

After all, RDV spredsheet only must compute the CSI/CDH/TPI by itself in order to offer a proper phasing solution to establish the proper geometry. If the solution is valid, from CSI point we don't need it anymore and its CSI/CDH/TPI solutions are for information only or at least as a backup.

Well, I did try using P32 and P33, but all it gave me was that the programs didn't exist. Is it possible that our Colossus build just doesn't support it?
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #37 on: August 16, 2011, 06:23:53 PM »

Quote
Is it possible that our Colossus build just doesn't support it?
Yepp. P32 and P33 came with Comanche (Apollo 10 to 14). Colossus (Apollo 8 & 9) never had that.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #38 on: August 17, 2011, 07:29:22 AM »

By the way P32/33 were not really required for the missions prior to Apollo 10.
If you look at the apollo7 phasing and rendezvous sequece, the NCC2 which I assume to be a sort of non planned CSI has not the same constraints than a true CSI: to be done at an apside point, horizontal burn etc. Moreover the ground had enough time to compute and uplink the burn data since the state vectors were stable and pefectly known.
Same for Apollo 9 and I dont speak about Apollo 8 which was a single ship mission.

From Apollo 10, they had to perform a rendezvous as it was expected to be in a lunar landing mission with the constraints of the far side overflying. During the far side coast from LOS to AOS ground didn't receive any telemetry and crew had to do it by himself.
Thing are even worse when a rendezvous occur after lunar liftoff due to uncertainty about the real position, launch and insertion dispersion and lack of time to update the state vector.
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #39 on: August 22, 2011, 06:17:55 AM »

Continuing to use 1.21, but now I'm getting circular reference warnings, and the display refuses to update to my new data.

EDIT: Found out that it was due to disabling iterative calc in response to the Excel freeze.
« Last Edit: August 22, 2011, 07:59:16 AM by eddievhfan1984 » Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #40 on: August 22, 2011, 10:50:49 AM »

Does it work now?
Logged
eddievhfan1984
Full Member
***
Posts: 231



View Profile
« Reply #41 on: August 22, 2011, 11:11:30 AM »

I'm not entirely sure.

It recalculated like it should, but I ran the burns in my scenario, and when I switch to P34 guidance, it complained that there's no ignition burn for 27.45 degree elevation and 140 degree central angle.

SO DEFLATED. Sad
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #42 on: August 25, 2011, 02:28:46 AM »

May be you can try to change E and CENTANG while in P34 to see if the AGC find a solution.

By now, the essential limitation with RDV spreadsheet is computing the whole sequence and displaying only the nominal delta V's for each burns. It means it assumes that each burn is perfectly done which, of course, it's nearly impossible to do.
So, in real time while running the simulation, dispersions grow up step by step until the relative position of the 2 vessel is wrong and the predicted TPI may be unfeasible.
Moreover, since the perturbation is not taken into account, the dispersion grows up more rapidly.
For example, with the default RDV State Vector, the target's computed orbital period is 5371 sec. It does match the orbit MFD at time of SV update simply because it's the period of the osculating orbit at this time. While working on the perturbation in J2, I’ve found that the mean apsidal period is around 5369 sec. In phasing and rendezvous practice, the period is an essential parameter such as the 2 sec difference in period makes the RDV solution too far from the actual one.

Currently I’m working on RDV 2.0 version which includes 2 important improvements:

First, the nonspherical gravity field perturbation is incorporated in the calculations (in J2 only, I neglected the other harmonic coefficients) so the whole geometry should be accurate enough.

Second; I plan to add something like two modes ability for the RDV to work:
 - A “plan mode” the user uses to build the sequence just like he does in the current version.
 - A “fly mode” the user switches to when the sequence has been built and while running the sim. In this mode the user would be allowed to update the SV between each burn and the spreadsheet would compute the next step burn data according to the new SV.

I got a lot of work in real life so I probably won’t be able to release this new version within at least 2 or 3 weeks. 

Meanwhile, you may try to disable the orbiter’s nonspherical gravity field to see if things go better.
An alternate is to disregard the RDV delta V’s and to use IMFD to find the burn solution to match the predicted orbit computed by the spreadsheet.
An other Idea: IMFD is able to find solution for offset target intercept. May be this would work using the spreadsheet range as the IMFD offset value?
 
Logged
meik84
Project Team Member
Sr. Member
****
Posts: 299



View Profile
« Reply #43 on: August 25, 2011, 06:59:34 AM »

Quote
May be you can try to change E and CENTANG while in P34 to see if the AGC find a solution.
I'd even set E to +00000. This handy little CMC is able to compute E by providing it with CENTANG and TIG. If this doesn't work, you should play around with TIG. The CMC tries to find a solution which is +/- 15 min of the given TIG, which is quite a narrow margin, especially when you did the preceding maneuvers "in the blind".
Logged
pattersoncr
Project Team Member
Full Member
****
Posts: 162


View Profile Email
« Reply #44 on: January 05, 2013, 12:27:18 PM »

Christophe, are you still working on this?
I tried it out but I'm getting really screwey results:
First, I loaded SV from prior to sep.  I performed the ~6fps phasing burn specified by the spreadsheet but by 12hrs GET the range between the CSM and S-IVB was over 1500km (based on Docking MFD) ovbiously this isn't right.
Next, I ignored the spreadsheet and ran separation and the 2.5fps retrograde phasing maneuver specified in the NASSP flightplan.  About 2 hours later, I loaded MJD and SVs into the spreadsheet and tried to calulate things from there.
Once I get the spreadsheet set up, however, it shows a range between the CSM and S-IVB of 129nm at the time of the target sep maneuver (which I set to be less than 1 min after the SVs were copied).  The problem is that the actual range at the time is only 8.2nm (Docking MFD shows 15.2km)  Shouldn't the parameters at target sep maneuver just be the SVs projected forward to the specified time?
Anyone else mess with the RDV spreadsheet and have any idea what's going on?

* RDV_1.21 Apollo 7 - 2.xls (483 KB - downloaded 19 times.)
Logged
Pages: 1 2 [3] 4 Print 
« previous next »
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!