Meadville Space Center
Welcome, Guest. Please login or register.
September 23, 2017, 12:47:30 AM

Login with username, password and session length
Search:     Advanced search
24444 Posts in 2077 Topics by 2260 Members
Latest Member: lricca
* Home Help Search Login Register
+  Meadville Space Center
|-+  Project Apollo - NASSP
| |-+  Project Apollo - NASSP Development (Moderators: movieman, Tschachim, Swatch, lassombra)
| | |-+  Virtual AGC
« previous next »
Pages: 1 ... 50 51 [52] Print
Author Topic: Virtual AGC  (Read 129228 times)
indy91
Hero Member
*****
Posts: 1282


View Profile
« Reply #765 on: June 02, 2017, 12:20:41 PM »

Do you also still not get the mission timer running in old scenarios? Because that was definitiely fixed in this commit: https://github.com/dseagrav/NASSP/commit/22f41d65dd56fe967654c2908f54dd014489d2c2

EDIT: More progress. I have only one explanation for not entering P74 and that is that Sunburst senses the Stage Verify bit different than all later AGC versions. So I can only assume that the Stage Verify signal is inverted in LM-1. If I change our staging code with that assumption then everything works as expected. At the end of P44 Abort Stage is commanded, the APS starts firing and Program 74 gets started. This is a short APS burn, only a few seconds. It nominally went into P00 and I am currently in the coasting phase until the second APS burn.  Thumbs Up
« Last Edit: June 02, 2017, 02:49:25 PM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 730



View Profile
« Reply #766 on: June 03, 2017, 01:30:35 AM »

I did a recompile and now the timers work fine. However, to implement the gimbal trim fix, which erasable memory location should I mod? Or is it in the github discussions?

EDIT: I also figured out why I was having such a tough time finding the source of the aborts. The ALMCADR registers stored information related to the 316 restart failure—searching for the memory word 16003 led to the entry point for the V74 call prior to bank switching, 2001 being the CADR of the restart call. Essentially, the ALMCADR info provided almost no help at all in this case. Tongue

EDIT2: Got the updated scenario from Dropbox, DPS1 runs like a dream.
« Last Edit: June 03, 2017, 02:59:50 AM by eddievhfan1984 » Logged
Thymo
Full Member
***
Posts: 93


View Profile WWW Email
« Reply #767 on: June 03, 2017, 04:35:16 AM »

You need to modify FORCETRM to say -0 to fix the GTS.

Here are my IRC logs from the last two days where we discussed all this and how we got to the fix. Might be an interesting read.
https://paste.pound-python.org/show/OmAVPsDHc5s1kdHC3w2L/

https://paste.pound-python.org/show/HaUCOga6JCxNBqpCnS0K/
Logged
eddievhfan1984
Hero Member
*****
Posts: 730



View Profile
« Reply #768 on: June 03, 2017, 06:03:08 AM »

YOU are a steely-eyed missile man, nuking the erasable to backtrace the CCSHOLE. If I had the money, I'd buy you the intoxicating beverage of your choice.

Thankfully, Luminary has way better backtracing.

So, I'm doing DPS2 now, should my roll be in gimbal lock zone for the out-of-plane burn? I expected an alarm and light, but didn't get one.
Logged
indy91
Hero Member
*****
Posts: 1282


View Profile
« Reply #769 on: June 03, 2017, 07:00:13 AM »

YOU are a steely-eyed missile man, nuking the erasable to backtrace the CCSHOLE. If I had the money, I'd buy you the intoxicating beverage of your choice.

Thankfully, Luminary has way better backtracing.

Yep, really brilliant procedure to get the alarm data for the 1103. When we had those numbers, then the problem was easy to find.

Quote
So, I'm doing DPS2 now, should my roll be in gimbal lock zone for the out-of-plane burn? I expected an alarm and light, but didn't get one.

Well, remember that the FDAI is displaying converted angles and not directly the ones from the IMU, so it's not always easy to tell if you are actually in gimbal lock or not.

As I said above, I think the Stage Verify bit works differently in LM-1/Sunburst. So to be able to start P74, the program running after stage separation, you have to change in lemmesh.cpp, function SetLmAscentHoverStage():

Code:
agc.SetInputChannelBit(030, DescendStageAttached, false);

to

Code:
agc.SetInputChannelBit(030, DescendStageAttached, true);

The LGC can send the staging command to the LM Programer. The right moment to do this manually is after the random throttle command sequence in Program 44. So after about 10 minutes of DPS-2 burn it switches from P42 through P43 to P44. The throttle commands are: 10%, 50%, 30%, 40%, 20%. Each for 10 seconds, I think. After the 20% it commands 100% throttle and then staging is supposed to happen 1 second after 100% was commanded. That's when you have to press Abort Stage. Don't forget to start all the ascent batteries before that though.

Right now the APS-2 burn runs until the propellant is depleted. And the orbit after burnout is not good, perigee below 0NM. Maybe after 10+ minutes in Average G during the DPS-2/FITH/APS-1 burn the state vector is finally inaccurate. Sunburst supports a state vector update, I'll work on making that work with the RTCC MFD and maybe APS-2 works better then.
« Last Edit: June 03, 2017, 07:03:44 AM by indy91 » Logged
eddievhfan1984
Hero Member
*****
Posts: 730



View Profile
« Reply #770 on: June 03, 2017, 08:16:18 PM »

If the AS-number is properly set for Apollo 5, can I use that to invert the staging logic, without breaking the other scenarios?

EDIT: Already done...

Code:
if(this->ApolloNo==5)
{agc.SetInputChannelBit(030, DescendStageAttached, true);}
else
{agc.SetInputChannelBit(030, DescendStageAttached, false);}
« Last Edit: June 03, 2017, 11:48:22 PM by eddievhfan1984 » Logged
Thymo
Full Member
***
Posts: 93


View Profile WWW Email
« Reply #771 on: June 04, 2017, 05:58:51 AM »

Do either of you have a branch I can checkout? I might want to try this myself.
Logged
eddievhfan1984
Hero Member
*****
Posts: 730



View Profile
« Reply #772 on: June 04, 2017, 08:38:01 AM »

The Apollo 5 stuff is on the Orbiter2016 branch. Just add in my code below to lemmesh.cpp to enable the proper staging logic.
Logged
indy91
Hero Member
*****
Posts: 1282


View Profile
« Reply #773 on: June 04, 2017, 10:42:27 AM »

I created a new branch for it, but that branch had very experimental changes to make Sunburst work during launch in a CSM. Also, the only launch scenario with a Sunburst120 padload I currently have is also for the CSM. All of that is very hacky and not particularly useful if you actually want to fly the Apollo 5 mission. So if there is no specific need for a prelaunch scenario, then I would consider the post-insertion scenario I posted as the starting point for any Apollo 5 mission. For now at least.

Regarding the Stage Verify input bit, it can either be done as eddievhfan1984 posted above or we are adding a flag for scenarios, that switch between inverted and non-inverted input bit.
Logged
Thymo
Full Member
***
Posts: 93


View Profile WWW Email
« Reply #774 on: July 06, 2017, 04:03:45 PM »

A new version of the custom Comanche055 rope for Apollo 10 has been pushed.
Apparently some typo's were missed last time in the planetary inertial orientation constants.
Logged
indy91
Hero Member
*****
Posts: 1282


View Profile
« Reply #775 on: September 05, 2017, 12:45:25 PM »

I've added the binary for Zerlina56 to the repository. Attached to this post is a testing scenario at PDI minus 2 minutes. As explain a bunch of posts above, Zerlina was a development version of the LGC software. Zerlina56 specifically is almost identical to the Luminary version flown on Apollo 14, except for a few features in development; some of which eventually made it into Luminary and a few others didn't.

A few remarks about the scenario. There currently is no really good way to test it except for changing the LGC version used by Apollo 14 in the NASSP code. In LEMcomputer.cpp find the line

Code:
binfile = "Config/ProjectApollo/Luminary210NBY71.bin";

and change it to

Code:
binfile = "Config/ProjectApollo/Zerlina56.bin";

I'll work on implementing an easier way to switch around AGC versions.

The scenario uses a landing site north of Tycho crater. For a good landing I suggest the following procedure. After ignition give the LGC a landing site update with Noun 69, about 6000 feet. The procedure is V21 N69E -06000E. Then, due to the rough terrain and many craters on the approach, don't allow landing radar updates until about 32NM before the landing site. The range can be found in R1 of N68. The terrain model I used for this mission only considers these last 32 miles before the landing site. In P64 do a bunch of LPD corrections to the left. Only then will you be able to find a flat landing spot. There are really not many places at the north rim of Tycho to land on.

Zerlina56 has a few special features as compared to Luminary. The first difference you will notice is that in P64 it doesn't show the time left to make LPD corrections in R1 but the forward velocity instead. The main differences of Zerlina are in P66. There are two experimental features, both of which never made it into Luminary, so they were never flown on an actual mission. P66 LPD and P66 velocity redesignation. P66 LPD shows you, very similar to P64, the angle on the LPD window markings where the LM will land. This is done under the assumption that the astronaut is currently in control of the LM, so the PGNS Mode Control switch is in Att Hold. If the LPD angle on the DSKY shows the landing spot where you want to land, then switch to Mode Control - Auto and the computer will null your forward and lateral velocities and start hovering over that landing spot. Altitude rate always has to be chosen manually with the ROD switch in P66.

The velocity redesignations can be done with the Mode Control switch in Auto. If you then use the ACA as if you were giving LPD commands, then the LM will increment the forward/lateral velocity by 1 ft/s. This way you can control a direction for the LM to fly with the computer in fully automatic control. To initiate an automatic landing you then have to cycle the mode control switch from Auto to Att Hold to Auto and then whatever you previously commanded as the velocity will be 0 again.

All of this is also explained in more detail in this Luminary memo: https://www.ibiblio.org/apollo/Documents/LUM171-DE_text.pdf

EDIT: Updated scenario with fixed scaling for TAUHZ.
EDIT2: Changed some gains in the scenario for the ROD throttle commands.

« Last Edit: September 13, 2017, 12:30:57 PM by indy91 » Logged
abr35
Project Team Member
Full Member
****
Posts: 91


View Profile
« Reply #776 on: September 13, 2017, 08:58:32 PM »

Just out of curiosity being the Zerlina scenario uses a hypothetical landing site: how possible is it to land at alternate sites right now? I can see it being relatively simple (using the RTCC MFD and creating a new terrain model) if the site chosen is at the same longitude as a historical site: like flying to Tycho with Apollo 14 or Copernicus with Apollo 12. What about somewhere like Marius Hills for instance? It is too far west for the proper lighting conditions, so none of the historical launch times work. This would mean having to update the TEPHEM, and I would assume the lunar polynomial among other things? It would boil down to just having to change the launch time, but how many part of the padload would be impacted? And can they be recalculated manually?
Logged
indy91
Hero Member
*****
Posts: 1282


View Profile
« Reply #777 on: September 14, 2017, 06:46:08 AM »

The historical launch times are the big issue. What I tried with Zerlina at first was to create a modified Apollo 14 launch scenario. For the perfect lighting conditions at Tycho you would want to launch about 12 hours earlier. But that time doesn't directly fall within a daily launch window. So you would have to either launch a full day earlier and plan the hybrid trajectory accordingly. Or you could launch at the same time as Apollo 14 and then adjust the free return pericynthion altitude to arrive at the right time at the Moon. I didn't have much success with these approaches. Usually the TLI DV was excessive. Right now I have no good tool to plan a lunar mission from launch to arrival at the Moon with minimal DV. Such a tool would have to optimize the launch time and insertion conditions and output the LVDC guidance presettings for TLI.

What I ended up doing was using an older Apollo 14 scenario after TLI, I copied over the Zerlina padload and simply accepted that I am on a suboptimal trajectory for Tycho. My LOI-1 had a DV of 4000 ft/s, 1000 more than usual. I flew everything according to the Apollo 14 flight plan, including DOI and the circularization burn. At that time the CSM had 18% propellant, probably not enough for TEI.

The Virtual AGC padload is a mostly solved problem, even for hypothetical landing sites. Lunar polynomial, TEPHEM, terrain model, all these things can be fairly easily adapted for another landing site or launch day. For that there are a bunch of tools, RTCC MFD for the terrain model, LTMFD for the lunar and solar ephemerides (although in the Orbiter 2016 version of LTMFD this feature was removed; Jarmonik gave me the source code for this and I will include it in the RTCC MFD at some point). I also am using a few MATLAB scripts for the correction vectors (AXO/AYO/AZO and 504LM). I really should publish my full process of creating padloads, so that other people can also do it with the tools I have been using. Just haven't gotten around to cleaning up my MATLAB scripts.
Logged
abr35
Project Team Member
Full Member
****
Posts: 91


View Profile
« Reply #778 on: September 14, 2017, 05:51:26 PM »

There was a NASA documentary on planning a lunar trajectory, but it was pretty rudimentary. Pick an azimuth that gets you to the antipode on time - launch to southern sites over the Atlantic and Northern ones over the Pacific. I guess what it would come down to is needing an "LOI Search" function that looks for the cheapest TLI by searching LOI times within a given range. But that would change the location of the moon at arrival, which means a new antipode, then a new TLI time, then a new launch azimuth. It would really all have to be done on the pad then, maybe even before opening Orbiter in some sort of mission planning spreadsheet. Probably not something necessary for a few versions yet.

Still, it's awesome to see the pace NASSP is moving at! I wouldn't of dreamed going to Tycho would've been close to possible in NASSP this year.
Logged
Pages: 1 ... 50 51 [52] 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!