Meadville Space Center
Welcome, Guest. Please login or register.
May 25, 2020, 11:45:51 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
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] 2 3 ... 16 Print
Author Topic: Apollo RTCC MFD  (Read 38234 times)
indy91
Hero Member
*****
Posts: 1316


View Profile
« on: February 24, 2015, 05:57:29 PM »

The RTCC MFD is now part of Project Apollo - NASSP, so no need to download any version in this or other thread.

In this thread I will post the newest versions of my Apollo RTCC MFD. So far I have attached the newest file randomly to my posts, but I don't think that is a very good idea. So don't look any further, this is the place to download from now on.  Very Happy

Currently the features of the MFD are:

-Calculating a Lambert-targeted Maneuver (Useable for the Apollo 7 phasing, NCC1 and TPI maneuvers)
-Calculating coelliptic maneuvers (Usable for the Apollo 7 NSR burn)
-Calculating Orbital Adjustment burns (Can be used for the Apollo 7 SPS burns no. 3-7)
-Calculating Deorbit and trans-earth Midcourse Correction burns (based on the P37 precision trajectory computations, also calculates the ignition time and splashdown coordinates.)
-Calculating the IMU transformation matrix (REFSMMAT) for the Alignment for Thrusting Maneuvers, Landing Site, Passive Thermal Control (PTC), Reentry Maneuvers and Alignment to Local Vertical at a specified time.
-Uplinking to the AGC the solutions for: CMC Desired REFSMMAT Update, CMC External Delta V Update, CMC Retrofire External Delta V Update, CMC Entry Update
-Displaying the Maneuver PAD and Entry PAD for a burn or reentry calculated with the MFD



Just a quick explanation of the newest as of right now quite outdated Reentry and REFSMMAT feature:

Open the "Apollo 7 at 4h09m GET.scn" file (or your own save around that time) and follow the Apollo 7 Preliminary Flightplan. At 04:45 GET there is a big Mission Control update. First let's do a state vector update with the Project Apollo MFD and then let the UPTLM CM switch in the Accept position. Open the Apollo Rendezvous MFD and go the the Entry screen. There you have to type in the desired landing coordinates and a predicted deorbit time. The landing site no. 4(?) has a longitude of about -162, which is 162W. The latitude number isn't currently used in any calculation, but if you know the actual desired splashdown coordinates, you can use that number as a reference.

The estimated 6-4 deorbit burn GETI is at 8:55 GET, but because the ignition time prediction is kind of tricky atm, a number larger than 009:00:00GET will predict a deorbit burn during the correct orbit and not an orbit too early.

Press CLC to calculate the burn and new landing coordinates. I get these numbers: DV components -619.4 +0.0 +155.8, displayed in the P30 format and in feet per second. The predicted splashdown coordinates. 27.38 N, 162W. Press UPL to start the P27 uplink program. Now that the AGC is busy with getting the new data, go back to the main menu and go to the REFSMMAT page. There you can calculate the reference matrix for the deorbit burn that gets used for the next few hours. Press OPT to change the option to "P30 retro" and press CLC to calculate the matrix. If the MFD has finished uplinking the reentry burn data you can then uplink the new REFSMMAT, too.

With the MCC Update finished, continue with the flight plan. The important parts are the P30 External Delta V and the P52 option 1 realignment. At about 7:30GET you get a No-Go for 17-1 (because of a malfunction, or Deke Slayton fired Wally Schirra on the fly or something like that) and you have to deorbit at the calculated time. Do the usual reentry preparations and hope, that my MFD did a good job with the deorbit burn. If the REFSMMAT is correct and the S/C Roll is at 180, P40 should come up with exactly 180, 180, 0 for the deorbit burn.
« Last Edit: September 15, 2016, 09:56:09 AM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #1 on: February 24, 2015, 07:31:57 PM »

Coolness, although I think "Apollo RTCC MFD" might be a better title at this point. LOL
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #2 on: February 26, 2015, 09:50:15 AM »

Haha, I guess that is true. It just seemed a little bold to me, to call it that Ashamed

Also, I didn't want to rename it yet again. If it ends up being the Apollo Rendezvous MFD, Apollo RTCC MFD, or part of the Project Apollo MFD. I can do either of these things, but I don't feel it is up to me to decide that. I do whatever you guys think is the best way for a release. I'm good at the complicated math behind it all, but not so much making it user friendly. I personally don't like juggling with 20 different MFDs  ROTFL
« Last Edit: February 26, 2015, 10:10:44 AM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #3 on: February 26, 2015, 01:11:45 PM »

I do have a Lambert targeting routine question I'd like to ask, though: is there a routine that can be written for doing minimum-dV targeting? I mean, it's relatively straightforward in NASSP, since the times and targets are historical, but just something I was thinking of...
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #4 on: February 26, 2015, 02:51:33 PM »

Hmm, what kind of scenario do you have in mind?

Solving Lambert's problem is essentially the determination of an orbit from two position vectors and the time of flight. So there are a few parameters you can change to find a lower Delta V. In the optimal case, you usually end up with something like a Hohmann transfer (180 transfer) or something like the Stable Orbit Rendezvous technique (360 transfer), used for the Space Shuttle.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #5 on: March 31, 2015, 06:35:09 AM »

So I have implemented the P37 precision trajectory calculations and it's basically what P37 does, but it is all in a loop to find the correct time for the deorbit maneuver. That leads to a problem, because it is a lot of calculations that has to be done in an instance. So Orbiter often freezes for a second or two after pressing the calc button. I'm not experienced enough with Orbiter and C++ to know the perfect solution for this, but I guess I will have to modify the function so that it spreads the calculations out over a few steps.

I also looked at what is missing to get a complete P30 Maneuver PAD and relatively easy I could implement the sextant star check. It only works with the REFSMMAT and External DV calculated in my MFD so far, but I can take the REFSMMAT out of the equation, I guess. Usually all maneuvers are done heads-down (if possible), except the reentry burn, right? Of course if it is desired to calculate the IMU gimble angles, too, I would need to somehow get the REFSMMAT currently stored in the CMC. And if I manage to do that, then my MFD has become a proper RTCC MFD Very Happy
Logged
eddievhfan1984
Hero Member
*****
Posts: 737



View Profile
« Reply #6 on: March 31, 2015, 06:02:26 PM »

Well, it should be possible to downlink the REFSMMAT coefficients from the AGC, or so I imagine (I'm assuming you're not using the "ground" reference to determine the gimbals, but the current IMU alignment + drift). As for the freeze-up, the problem may be that the steps performed in the MFD temporarily take priority over the other Orbiter functions. Off the top of my head, I figure if you could get it running in parallel or on a lower-priority task, it would solve the freeze, because Orbiter does the same thing during CSM/LV sep or an abort initiation.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #7 on: April 02, 2015, 09:39:26 AM »

I "solved" it by improving the coasting integration function. The accuracy parameter I used was kind of overkill, it was basically a modified coasting integration routine of the AGC, but with the accuracy 10x higher. I set that number a little bit lower without any real impact on accuracy. And each iteration to find the deorbit time and DV vector is now called on successive frames. I currently use a crappy netbook, so for most people it should be ok. I guess I will know, when people other than me have tested it.

Another result of the improvements of the coasting integration function is that it now works in cislunar flight, i.e. it takes the gravity of the Sun and Earth into account, when the CSM is on the edge of the Moon's sphere-of-influence. With that I can now calculate e.g. a LOI REFSMMAT long before the spacecraft reaches the moon. An accurate LOI-2 REFSMMAT would be a real challenge though, because there are two maneuvers (MCC-4 and LOI-1) between the historic time of uplinking that REFSMMAT and LOI-2. At this time I don't see the need to calculate all of that just to get it really, really accurate. What my MFD can currently calculate is perfectly fine to use with the ORDEAL, which needs an in-plane alignment.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #8 on: April 07, 2015, 11:22:02 AM »

Update: I have done significant modifications to the trajector propagation method of the MFD. It should now work in the whole Earth-Moon-System.

The reentry maneuver calculations do now include the precision part of P37, so it should be very accurate.

I have also added the sextant star check. And with that my MFD could basically calculate a whole Maneuver PAD?! I have been thinking about this a little bit, I think it would be pretty nice, if my MFD could output a finished Maneuver PAD and Entry PAD. I mean, I like the "going through extensive checklists" part of flight simulators and while a complete PAD is not really necessary to perform a maneuver with NASSP, it would be more realistic. Anyway, I hope for some feedback on the updated MFD Happy
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #9 on: April 08, 2015, 02:29:06 PM »

Hey indy91, nice work!

About the maneuver pad, impressive work on the sextant star check, I guess the last thing for the pad would be to get the RPY gimbal angles for a given P30/40/41 maneuver so we could use V49 to manually enter the angles before using P30/40/41. Maybe something like a conversion page that shows what the RPY angles are for a given Vx,Vy,Vz.

Alex
« Last Edit: April 08, 2015, 02:33:04 PM by jalexb88 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #10 on: April 08, 2015, 04:12:38 PM »

Thanks! Yes, I think that would be possible. The IMU angles depend not only on the Delta V vector of the burn, but also the currently used REFSMMAT. A maneuver that uses one of the two types of maneuver REFSMMAT my MFD can currently calculate ("P30" and "P30 retro") has always the same RPY angles anyway: 0, 0, 0 and 180, 180, 0 respectively. But of course the platform is not always aligned with a burn attitude. During the entire Apollo 7 rendezvous it kept the same alignment. That alignment came from a P52 option 2 (nominal alignment), which was done at 23:05h GET with a T-Align (N34) of 23:24:08 GET.

My MFD can calculate a nominal REFSMMAT, too, it's the option "LVLH", alignment to the Local Vertical, Local Horizontal at a specified time. So what I could do without knowing the REFSMMAT currently stored in the CMC, is use that to reproduce the alignment in the CMC with my MFD. You would just need to do a P52 option 2 and then calculate the LVLH REFSMMAT at the exact same GET and then calculate the IMU angles from that. I will try that and report back.
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #11 on: April 09, 2015, 05:02:57 PM »

Another Update to my MFD: I fixed a few bugs in the Entry Targeting and more importantly added a Maneuver PAD page. It's not very pretty yet, but it has most of the relevant information. To test the newest features I suggest trying this sequence:

1. Launch Orbiter with the "Apollo 7 at 23h GET" scenario from the zip file.
2. Open the Apollo Rendezvous MFD and calculate the Lambert-targeted NCC1 burn as usual (you'll find how to do this in the manual).
3. Then go to the REFSMMAT page, change the option to LVLH and calculate a nominal alignment for 023:24:08 GET (the historical alignment Apollo 7 had for the Rendezvous sequence). Now the MFD knows which alignment the CMC will have.
3. Do a P52 option 2 with the same T-Align.
4. Go to the Maneuver PAD page of the MFD and choose the option "Heads-Up" and press CLC to calculate the missing numbers of the Maneuver PAD.
5. Perform a Crew Defined Maneuver with V49 and use the RPY values on the bottom the Maneuver PAD page (don't forget that the fomat is XXX.XX).
6. Once you have reached the correct attitude and you see the flashing 50 18 press ENTR to clear the DSKY.
7. Now the sextant star check: Make sure the Optics are in CMC mode, key V41 N91E and then the two angles (shaft and trunnion) from the Maneuver PAD page. If everything went well you can now see the star in the sextant.

I will think about options to make the page look a little bit less cramped. And I guess the next update to my MFD will be the Entry PAD, which isn't that much more work, now that I know how to do that kind of stuff.  Thumbs Up
Logged
jalexb88
Sr. Member
****
Posts: 328


View Profile
« Reply #12 on: April 10, 2015, 03:10:54 PM »

The PAD page is quite impressive, I've been waiting a while to see something like this! Your procedure worked flawlessly. About the REFSMMAT, and I think you mentioned this but would it  be possible for your MFD to read the current REFSMMAT stored in the CMC? Also, I noticed the REFSMMATs calculated in the MFD are not saved in the scenario files meaning that we always have to calculate a new one for the PAD (and do an P52 option 2) when reloading a saved mission, or is there another way to recover a REFSMMAT previously used by your MFD in an earlier session? I think this would be a non issue if the REFSMMAT is read straight from the CMC. Hope that all made sense.

Alex
« Last Edit: April 10, 2015, 03:24:39 PM by jalexb88 » Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #13 on: April 10, 2015, 05:22:13 PM »

The MFD can already uplink data to the CMC, so downlinking stuff like the REFSMMAT should be possible. I have just not found out how to do it properly. I'm not sure, if I have to do a whole downlink procedure like the GroundStation.exe, or if there is any easier way to access data stored in the computer. But recreating the REFSMMAT with my MFD, as described in my post above, is only the temporary solution.

As for saving the state of the MFD, that is something I am really not looking forward to do, even though I probably should implement that at some point. There are sooo many variables already in the MFD and I guess I would have to rewrite the code a lot to save it with the scenario.

And for anybody wanting to try the Entry Targeting functionality of the MFD: I have discovered a few problems with it. It will work in exactly 50% of all cases, but it also might freeze the simulation or produce nonsense. I haven't yet found the source of the problem though...
Logged
indy91
Hero Member
*****
Posts: 1316


View Profile
« Reply #14 on: April 12, 2015, 03:05:43 AM »

I've fixed the problem with the reentry calculation (I think) and added a very basic Entry PAD with only the numbers that were straightforward to calculate.

I haven't gotten around to add the whole Entry procedure with my MFD to the manual yet. You give it an estimate of the Deorbit Burn time of ignition and the desired splashdown longitude and reentry angle and it will give you the correct TIG, splashdown coordinates and deorbit burn numbers. Uplink the data and you will have the numbers for P30 and also Noun 61 (splashdown coordinates) in the CMC. Then calculate the Retrofire REFSMMAT with the option "P30 retro", uplink that too, and do your usual reentry stuff. In theory the calculations should be more accurate than P37, because P37 assumes an oblate Earth. I have gotten pretty good results so far.
Logged
Pages: [1] 2 3 ... 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!