Meadville Space Center
Welcome, Guest. Please login or register.
July 11, 2020, 05:20:45 PM

Login with username, password and session length
Search:     Advanced search
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Apollo RTCC MFD
« previous next »
Pages: 1 ... 12 13 [14] 15 16 Print
Author Topic: Apollo RTCC MFD  (Read 38687 times)
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #195 on: September 15, 2016, 01:48:19 PM »

Alright I'm trying the DOI function off the undocking scenario you posted. Correct ignition time, Long, Lat, Alt.  However the resulting burn is a prograde one?  Confused HA: 115 NM HP: 60 NM  Its the correct velocity, but prograde.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #196 on: September 15, 2016, 01:57:47 PM »

Oops, that's what I get for not testing properly. I think it's just a reversed sign. Will be fixed shortly.
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #197 on: September 15, 2016, 05:23:46 PM »

Fixed it! But I read P30 uplinks should be working, however nothing happens when I try... Data switch and P00 are set.

EDIT: I was using the scenario "Apollo 11 - Post Undocking" from the LM status thread and for some weird reason I couldn't do the uplinks. Now I've tried the "Apollo 11 - LM P63 Test (Tranquility Base texture)" and it works.

Another problem is that on some pages in the LEM like the orbit adjust page, I get a CTD when I push calculate. I do the exact same maneuver calculation from the CSM and it works.
« Last Edit: September 15, 2016, 06:01:02 PM by jalexb88 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #198 on: September 16, 2016, 03:50:26 AM »

Fixed it! But I read P30 uplinks should be working, however nothing happens when I try... Data switch and P00 are set.

EDIT: I was using the scenario "Apollo 11 - Post Undocking" from the LM status thread and for some weird reason I couldn't do the uplinks. Now I've tried the "Apollo 11 - LM P63 Test (Tranquility Base texture)" and it works.

I think this has to do with the PCM bitrate switch, which has to be in the low position.

Quote
Another problem is that on some pages in the LEM like the orbit adjust page, I get a CTD when I push calculate. I do the exact same maneuver calculation from the CSM and it works.

Haven't added the LM capability to those functions. The only problem really is the finite maneuver time compensation. It is looking for the thrust and isp of the main engine, but in Orbiter terms the LM doesn't have a main engine. It has a hover engine. So that's where these calculations are causing the CTD. Shouldn't be too much effort to make the CDH, orbit adjustment etc. work with the LM. Even TEI with the LM should be possible, although docked burns with full DPS propellant doesn't work too good yet.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #199 on: November 21, 2016, 04:20:44 PM »

I have added the body relative angles to the RTCC MFD, which was talked about here: http://www.ibiblio.org/mscorbit/mscforum/index.php?topic=2863.msg24624#msg24624

It enables you to calculate the RPY angles for pointing any axis of the CSM towards any body in the solar system. If you are confused by the axis, for an astronaut looking out of the rendezvous window up is "-Z", forward is "+X" and right is "+Y". There are no additional constraints yet, so it is very possible that the MFD will calculate an attitude in gimbal lock. I can implement some LGC routines that could prevent this, but that will follow later.

This new feature is useful for at least the Apollo 7 SPS Propellant Thermal Control Test. The actual RTCC was also able to calculate the angles to point a specific point on the CSM towards the sun, so the MFD now fulfills this RTCC (or rather RTACF) requirement.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #200 on: February 11, 2017, 07:34:54 AM »

I've spent the last week implementing some of the Skylark guidance equations into the RTCC MFD. All the rendezvous maneuvers can now be calculated in the MFD and I have successfully performed a rendezvous with this profile used during Skylab and ASTP. There are still a few issues, but I'll get to that later. This is for Orbiter 2016 only, I won't make any changes like this to NASSP 7.0 anymore. Also, this is a big update so expect bugs.

The Skylab rendezvous profile is an extension of the concentric profile for Lunar Orbit Rendezvous used by Apollo 11 and 12. Here a picture:



NC1 is a phasing adjustment maneuver and NC2 is a height adjustment maneuver. In combination the DVs of these two maneuvers control the time of TPI, which usually is supposed to happen at around orbital midnight.

The NCC maneuver is Lambert-targeted, so it is setting up the NSR maneuver at the exact right location. The NSR maneuver then eliminates all the remaining out-of-plane velocity and sets up the coelliptic phase of the rendezvous. The NSR maneuver, sometimes called CDH is a maneuver we are already familiar with, because it is part of the normal Apollo rendezvous sequence.

The TPI maneuver is calculated at a specific elevation angle to the target vehicle. And then there are two midcourse corrections. That's all standard Apollo stuff.

All these maneuvers could be calculated onboard with the Skylab and ASTP AGCs, but there are some procedural differences to the ground targeting, which I have already partially implemented in the MFD. The "Skylab Rendezvous" page in the RTCC MFD can be found on the second main menu page. There are 8 sub pages: TPI Search, NC1, NC2, NCC, NSR, TPI, TPM and NPC. NPC is plane change targeting, which could be necessary if insertion didn't happen all that precisely.

I'll attach a scenario to test the Skylab rendezvous. The scenario will start before the NC1 maneuver and I have flown the maneuvers in such a way that I replicated the insertion maneuver with a GET difference of 6 hours. I have created the scenario from an Apollo 7 scenario and the target is the Apollo 7 S-IVB. If you want to use the onboard targeting, the AGC version we use for Apollo 7 can only be used for the TPI and TPM maneuvers.

The first step is to find the correct time for TPI. On the "TPI Search" page you can give the MFD an initial guess and it will calculate the time of orbital midnight. I might add an input for an offset time at some point. So press TGT until the target "AS-205-S4BSTG" is selected. The reference profile I have used, the Skylab 4 mission, had a TPI time of about 006:45:00 GET, so with the 6 hours difference, use 12:45:00 as the input. I usually get about 13:16:00 GET as a result.

On the NC1 page there are several inputs to make. The Skylab 4 NC1 maneuver happened at 2:20:54, so use this an an GET input (EDIT: plus 6 hours of course). Alternatively, you can time "ApT" and it will calculate the next apoapsis as the NC1 time. But that might be one revolution to early, depending on when you let it calculate the next apoapsis.

The normal profile has 1.5 orbits between the NC1 and NC2 maneuvers, so use this as the N input.

Now a number I actually don't really have a source for. The DH at NCC "DH1" is an input only used during the NC1 targeting, so it's a simplification to make the calculations less complicated. I have used 20NM here, but just because it looks like the correct altitude difference from a few documents I found. The Skylab Rendezvous Book doesn't have this information for some reason. Right now I think it was pad loaded and, while it is a crew input during the NC1 program, the astronaut could simply PRO through the program with these numbers already loaded.

The second DH "DH2" is the coelliptic DH, so use 10NM here. The elevation angle at TPI is 27.0, which is the "EL" input.

Now the NC1 calculation can be made by pressing CLC. Uplink and Maneuver PAD calculation work as usual. There are also a bunch of preliminary numbers for the later maneuvers displayed on the right side of the "Skylab Rendezvous" page.

The NC2 calculation is essentially identical, just with the DH1 input missing, as explained above. The preliminary time calculated during the NC1 calculations is used as the NC2 TIG. This can be changed manually or again with the input "ApT", but I usually just use the TIG calculated before during the NC1 targeting.

The NCC targeting uses the same inputs as the NC2 maneuver.

The NSR is fixed at 37 minutes after NCC. The inputs are again the same.

The TPI targeting works like on the Lambert page in the MFD. The elevation angle input is used to calculate a new TPI TIG, which should be really close to the previously predicted time. Other than the Apollo 7 rendezvous the SPS is used for the TPI maneuver for this profile, to conserve RCS fuel.

TPM (Midcourse) targeting uses the TPI time and an offset time from TPI as inputs. I don't think there were any ground solutions for midcourse corrections during the Skylab/ASTP missions though.

The last page of the Skylab Rendezvous page is for a plane change. A plane change is done when the yaw angle of the Lambert-targeted NCC maneuver becomes unacceptable large, which is greater than 60 out-of-plane. This is likely to happen in my example scenario. The plane change targeting is also based on a Skylark program, but it can only be used in combination with a ground targeted NC1 (if really necessary the NC2) maneuver. If this becomes necessary, then the NC1 ground solution has an out-of-plane component setting up a node with the target orbit 90 and 270 later. The onboard targeting calculates the TIG as 90 later, the ground solution would be a plane change maneuver 270 later and this is what I have implemented in the RTCC MFD. So when you calculate the NC1 maneuver press the "NPC" button and the page will now say "NC1 with Plane Change". If you perform the NC1 in this way then a following NPC maneuver will null the relative out-of-plane velocity. On the NPC page pressing "PCM" cycles between using the NC1 or NC2 TIG as a reference. This should say NC1 if you have set up the plane change with the NC1 maneuver. The ground targeted NPC maneuver, which I have implemented in the RTCC MFD, adds a radially downwards velocity component to the maneuver so that a REFSMMAT change does not become necessary. The velocity component is chosen so that the yaw angle is about 70. So the Gimbal Lock light will go on, but if you are careful you won't actually get into the red zone.

Now to the issue which I don't fully understand yet. The NPC maneuver between NC1 and NC2 perfectly nulls the relative inclination. But because of the big orbit difference (CSM is still in a much lower orbit than the OWS, or in this case the S-IVB) the relative inclination will increase again due to nonspherical gravity. And my scenario must be a worst case scenario, because the relative inclination increases to such a degree that the NCC maneuver gets an unacceptable out-of-plane component again. How did they deal with this during the actual Skylab rendezvous? They certainly planned the insertion parameters so that the relative inclination would be 0 after the NC maneuvers. But it really seems like the onboard NPC targeting can become useless in some worst case scenarios. Maybe I have to adjust the RTCC MFD NPC targeting for that. The biggest influence on the NCC out-of-plane component is the altitudes at which NC1 and NC2 are performed. If you perform the NC1 maneuver 10 minutes before apoapsis then the NCC out-of-plane component is zero. By moving the TIG a few minutes plus or minus this out-of-plane component changes from 15 ft/s in one direction to 15 ft/s to the other direction. I don't quite know yet how to deal with this and I don't know how they handled this back in the day. A Skylab Operational Trajectory would probably help. Maybe we'll find one at some point.

I've looked through the transcripts a bit and I do know that the actually flown Skylab 4 profile was very different from the planned one. I only know the planned one for one day earlier than the flown mission, but the normal DVs for NC1, NC2 and NCC are 225 ft/s, 165 ft/s and 25 ft/s. Those are the hardcoded initial guesses for the maneuvers in Skylark. The planned and flown mission for one day later was 38 ft/s, 153 ft/s and 209 ft/s. So that is veeery different than the profile as in the image above. So I guess I still have a lot to learn about this rendezvous profile.

* Skylab Rendezvous Testing 0001.scn (104.03 KB - downloaded 75 times.)
« Last Edit: February 11, 2017, 10:00:29 AM by indy91 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #201 on: April 08, 2017, 09:56:33 AM »

A few changes in the MFD:

-Added a free return option for Translunar Midcourse Corrections. This is the options 6 and 7 of the Translunar Midcourse Correction Processor of the actual RTCC, for a free-return flyby to specified/nominal pericynthion coordinates. The targets are the Earth-Moon-Plane (EMP) pericynthion latitude and the pericynthion altitude. There aren't many good sources for the EMP latitude parameter, but it can be reverse engineered from Operational Trajectory documents. For Apollo 8 it was -5.67822. The next step would be developing something for the option 2 of the TLMCC Processor, which is the option that was actually used during Apollo 8 for MCC-1 and MCC-2. This option optimizes the full mission DV, especially LOI, in addition to ensuring free return. I think I have some good ideas how to accomplish that.
-Reorganized the MFD. All previous calculation pages are now categorized in: Maneuver Targeting, Pre-Advisory Data and Utility. Also, the MCC and LOI targeting are on seperate pages now. TLI and MCC on one page, LOI-1 and LOI-2 on another.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #202 on: April 08, 2017, 11:13:25 AM »

A few changes in the MFD:

-Added a free return option for Translunar Midcourse Corrections. This is the options 6 and 7 of the Translunar Midcourse Correction Processor of the actual RTCC, for a free-return flyby to specified/nominal pericynthion coordinates. The targets are the Earth-Moon-Plane (EMP) pericynthion latitude and the pericynthion altitude. There aren't many good sources for the EMP latitude parameter, but it can be reverse engineered from Operational Trajectory documents. For Apollo 8 it was -5.67822. The next step would be developing something for the option 2 of the TLMCC Processor, which is the option that was actually used during Apollo 8 for MCC-1 and MCC-2. This option optimizes the full mission DV, especially LOI, in addition to ensuring free return. I think I have some good ideas how to accomplish that.
-Reorganized the MFD. All previous calculation pages are now categorized in: Maneuver Targeting, Pre-Advisory Data and Utility. Also, the MCC and LOI targeting are on seperate pages now. TLI and MCC on one page, LOI-1 and LOI-2 on another.

This is awesome, and may I say I am continually impressed with the RTCC MFD's power.

I am wondering, however, if we can create pages on it that could help with a Docked DPS burn.  It appears Apollo 9 didnt uplink a target load and both the CSM and LM input a P30 from the Maneuver PAD.  I have run the same orbit adjustment numbers in both and I am using the P30 retro for the CSM and P30 heads up for the LM, however when I place the CSM at R300 P180 Y0 the LM is not at the P40 burn attitude suggested by the Maneuver PAD on the RTCC MFD or the angles requested by the LGC.  Would there be a way to simplify this procedure using the RTCC?
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #203 on: April 08, 2017, 11:52:14 AM »

This is awesome, and may I say I am continually impressed with the RTCC MFD's power.

I am wondering, however, if we can create pages on it that could help with a Docked DPS burn.  It appears Apollo 9 didnt uplink a target load and both the CSM and LM input a P30 from the Maneuver PAD.  I have run the same orbit adjustment numbers in both and I am using the P30 retro for the CSM and P30 heads up for the LM, however when I place the CSM at R300 P180 Y0 the LM is not at the P40 burn attitude suggested by the Maneuver PAD on the RTCC MFD or the angles requested by the LGC.  Would there be a way to simplify this procedure using the RTCC?

I'll have to look some more into the specific procedures they used here. But if both CMC and LGC have the same REFSMMAT and a good alignment then the IMU angles R300 P180 and Y0 in the CSM should always lead to the angles 0,0,0 in the LM. So if 0,0,0 was actually used in the LM for this burn, then the RTCC MFD can currently already calculate the correct REFSMMAT for the LGC, but not the CMC. So there should be an option for the CMC like "Docked P30" or so, which calculates the REFSMMAT so that the LM gets the 0,0,0 angles and not the CSM.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #204 on: April 08, 2017, 06:06:40 PM »

Do you mean the "P30 Retro" option? 
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #205 on: April 09, 2017, 12:29:29 AM »

Actually, I got confused there with the different orientations. All you need to do is use the normal REFSMMAT P30 option, heads down, in both CSM and LM. Then move to R300, P180, Y0 with the CSM and the LM will have the angles 0,0,0. A while ago I added the heads up/down options for the P30 (Preferred) REFSMMAT. I guess it got a little bit confusing, but previously the default option was heads down, because that is what the AGC can also calculate with P52 option 1.
« Last Edit: April 09, 2017, 12:44:09 AM by indy91 » Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #206 on: April 09, 2017, 08:52:22 AM »

Actually, I got confused there with the different orientations. All you need to do is use the normal REFSMMAT P30 option, heads down, in both CSM and LM. Then move to R300, P180, Y0 with the CSM and the LM will have the angles 0,0,0. A while ago I added the heads up/down options for the P30 (Preferred) REFSMMAT. I guess it got a little bit confusing, but previously the default option was heads down, because that is what the AGC can also calculate with P52 option 1.

So while in the CSM, do I need to choose "LM/CSM" as my vehicle to make sure the angles are correct?

EDIT: Guess it won't uplink to the CSM like that, so let me rephrase the question.  I run the Orbit Adjustment for the burn in the CSM, choose the P30 Heads Down REFSMMAT option in the CSM, and uplink that and run a P52?  Then align the LM to the CSM platform?
« Last Edit: April 09, 2017, 08:55:46 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #207 on: April 09, 2017, 09:02:06 AM »

So while in the CSM, do I need to choose "LM/CSM" as my vehicle to make sure the angles are correct?

The vehicle configuration won't have any influence on the REFSMMAT calculation.

Quote
EDIT: Guess it won't uplink to the CSM like that, so let me rephrase the question. 

Yeah, "LM/CSM docked" is the MFD configuration for the LM, with the CSM docked. "CSM/LM docked" is how it should be for the CSM. And then of course "LM/CSM docked" in the LM. But both of these configurations should be automatically detected and you don't usually have to change it, unless you have undocked since you started the MFD.

Quote
I run the Orbit Adjustment for the burn in the CSM, choose the P30 Heads Down REFSMMAT option in the CSM, and uplink that and run a P52?  Then align the LM to the CSM platform?

Yep. Also, don't forget to do the same steps in the LM. The LGC gets the same REFSMMAT. But in the LM you shouldn't do a P52 at that time but perform the docked alignment procedure. Then the LGC has the correct REFSMMAT and alignment. The CSM, too, of course.
Logged
rcflyinghokie
Hero Member
*****
Posts: 580


View Profile Email
« Reply #208 on: April 09, 2017, 09:24:31 AM »

Wonderful makes total sense now, the orientation thing was throwing me off as well but I see everything coming together now.  I am going to try a docked DPS burn, I have heard horror stories about it's stability though so we shall see what happens Undecided

EDIT:  I am still getting differences in the LM P40 desired angles and from the RTCC MFD both being something other than 0,0,0

I have added a scn file if you don't mind taking a look.  It is very close to burn time for that I apologize.

EDIT 2:  Sorry for being back and forth, but I think I forgot to uplink the new REFSMMAT to the LM, let me try that... Bangs Head 2

And that did the trick, and as expected oscillation began about 2 minutes into the Docked DPS burn.  For now I am going to try it with SM RCS assistance I think.

* Apollo 9 Day 3 Docked DPS Burn 0002.scn (160.61 KB - downloaded 73 times.)
« Last Edit: April 09, 2017, 11:18:48 AM by rcflyinghokie » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #209 on: April 11, 2017, 04:27:35 AM »

I have commited the optimized Translunar MCC targeting. This targeting tries to emulate option 2 of the TLMCC Processor of the actual RTCC. Option 2 is: Free-return, fixed LPO orientation, landing site. This TLMCC option uses the Best Adaptive Path (BAP) reoptimization, which essentially tries to minimize fuel consumption (or rather, maximizes the mass) for a complete mission.

In the RTCC MFD this is still much simpler and doesn't use a proper optimization tool yet. At some point I'll try to find and implement a good open source library for this. But it does optimize the MCC and LOI-1 as a pair, ensures free return and the correct lunar parking orbit orientation. For that, you need to check the Lunar Insertion page before you try the calculation. There all the parameters for LOI-1 should be set. For Apollo 8, 10 and 11 that is automatically the case already, because the mission specific parameters are loaded when you open the MFD. If all the LOI-1 parameters are correct go to the Translunar page, choose option 2, check all the input parameters there and calculate the MCC. Only Apollo 8 and 10 have all the parameters preloaded for this, but I'm looking into adding more missions. The MCC calculation can take a few seconds, especially for MCC-1. I'll try to improve that. Once the calculation is done, the targeting has also calculated a nodal target. This will appear on the page for option 1. Option 1 with this nodal target should be used for MCC-3 and MCC-4. Targeting these coordinates (GET, latitude, longitude, altitude) will ensure that the trajectory intersects the lunar parking orbit at the desired point. Previously only the nodal targeting was implemented in RTCC MFD and we used the nominal pericynthion state as the target parameters.

I have also already added the FR BAP targeting to the MCC-H functionality. It's tested until before LOI-1 and I got pretty good results for the TL MCCs and the LOI-1 solution.
Logged
Pages: 1 ... 12 13 [14] 15 16 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!