Meadville Space Center
Welcome, Guest. Please login or register.
October 24, 2020, 10:06:52 PM

Login with username, password and session length
Search:     Advanced search
Gemini 060615 released!
25068 Posts in 2094 Topics by 2266 Members
Latest Member: twa517
* Home Help Search Login Register
  Show Posts
Pages: 1 [2] 3 4 ... 15
16  Project Apollo - NASSP / Programming / Re: LM status... on: September 05, 2016, 06:03:28 PM
The first document appears to be a general spec document, the characteristics of each DPS engine were determined prior to flight and the numbers provided specifically for each flight. So in summary, don't expect your accurate value to match the generic one from the doc.

Fair enough, although our two examples of Luminary both use the same scale factor constant for bit/N.  Happy

That is interesting.....I will dive a bit more into this part of the code. Luminary specifics I'm sadly a little weak on.
17  Project Apollo - NASSP / Programming / Re: LM status... on: September 05, 2016, 03:58:52 PM

Ah, the +-10000 is probably just to peg it open or closed. I think pulses beyond the limits are just discarded. It looks like the lbf/count from THRUST is something like 2.7 (which I pulled from this document) or 2.868 which is what I get calculating it myself from this GSOP section 6.
(0.224809 lbf/N) * (3645 N/V) * (0.0035 V/bit) = 2.868... so I'm not sure what I'm missing for this to not match the 2.7.


The first document appears to be a general spec document, the characteristics of each DPS engine were determined prior to flight and the numbers provided specifically for each flight. So in summary, don't expect your accurate value to match the generic one from the doc.
18  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 22, 2016, 07:21:50 AM
The V40N20 is simply to ensure that the computer counter and IMU counters are not skewed. That's all it does. What has caused the initial confusion is that it appears in the NASSP implementation we are calling some kind of code that drives the IMU physically back to it's zero gimbal positions (the IMU itself doesn't know what this position is..the IMU cage logic does though).

So we have over complicated this because the effect of the incorrect implementation made us question it's use.

So in the end its an incorrect implementation in NASSP afterall.  Which would completely validate the checklists as they were written for the flights.  Would this be a simple fix to prevent the IMU resolver from running a 0,0,0 or cage logic?

I don't know the C++ code well at all. I suspect however that as we have an 'ideal' IMU without drift and other issues, we can simply actually ignore the CDU zero all together. I don't know the implementation in the IMU but it must send a pulse train to the AGC like the real thing. If it does then, as it doesn't sound like an internal ICDU counter is modelled at all it is irrelevant if we 'zero' it or not.

I'll leaev it to the programmers to determine what the best 'fix' is, however as far as I can see from a G and N perspective, an ideal IMU that ALWAYS (and it must be always) manages to increment the AGCs own counters, means we have no need for the ICDU / AGC counter sync.

I'll think on this overnight as I still possibly feel that unless we can ber certain our IMU is perfect and always updates the AGC fully, then we may in fact need to do this.
19  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 22, 2016, 12:08:36 AM
That's what I had kinda been thinking of, although I also thought that one of the quirks of the REFSMMAT alignment is that the REFSMMAT also identified the zeroed ICDU counter point. But I could see where I might make that mistake. I just remember how after the initial V41N20 and the V40N20, they'd do an angle compare (display freeze), and use that to do the initial V42 gyro torquing and fine align prior to a P52 on the LGC. So zeroing the error counters would kinda make sense in that regard.

I just wrote a long post about REFMMAT and how it could be used to provide 0,0,0 angles..but when I reached the end I realised that isn't actually anything to do with why the ICDUs and Computer CDU counters are zeroed....

You're correct I feel, the ICDU zero is fine in the context of doing a subsequent Fine Align AFTERWARDS. Because, you're going to subsequently torque and align the IMU to however it should be based on the REFSMMAT you select.

The V40N20 is simply to ensure that the computer counter and IMU counters are not skewed. That's all it does. What has caused the initial confusion is that it appears in the NASSP implementation we are calling some kind of code that drives the IMU physically back to it's zero gimbal positions (the IMU itself doesn't know what this position is..the IMU cage logic does though).

So we have over complicated this because the effect of the incorrect implementation made us question it's use.
20  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 21, 2016, 10:45:57 PM
It actually makes sense in retrospect. The CDUs count the torquing pulses used to align the gyros with the REFSMMAT (like a more sophisticated version of the SCS integrating attitude rate to derive orientation)

Yeah, that's the IRIGs. Inertial Reference Integrating Gyroscopes. I don't think we really simulate this.

Quote
and zeroing the counters effectively locks in the current orientation as the new reference for the CDUs. Or that's how it make sense to me...

If I change the code in the DoZeroIMUCDUs() method in the IMU so that the gimbals are not set to zero, then it looks like we get the intended behavior. I think. In that case only the attitude reference is reset, and the CDU counters are zeroed. But I'm not convinced or knowledgable about the IMU and CDUs enough to commit such a change already. I really don't want to break our IMU.


Ohhh. You've highlighted the problem. So it sounds like in our IMU the IMU CDU values are synonymous with the gimbal angles themselves?

This is NOT the reality of the actual IMU. Zeroing the ICDUs would only return the physical IMU to 0,0,0 if the error counters are enabled (which they usually are). I suspect our virtual IMU doesn't respond to the presence of the IMU error counter disable bit...this is the problem.

So zeroing the IMU CDUs with V40N20 simply resets both the IMU hardware CDU counters (with error disabled so the IMU doesn't torque to a new position). It then zeros the AGC CDU X,Y,Z counters.

If such a process is performed the only way to read the 'real' gimbal angles will be via an FDAI.

I'm beginning to see why such a procedure may be needed, in reality the computer CDU counters are updated by pulses received from the ICDU (IMU CDU) (triggering PCDU and MCDU 'unprogrammed sequences' for those who like the detail).

As the GSOP implies, it's possible that not every ICDU pulse is processed by the AGC. This would mean that the CDU computer counters no longer match the ICDU counters. So the computers record of the gimbal angles will be different from the actual physical gimbal angles.

Zeroing everything will get these back in sync, albeit all at 0,0,0. Now what I'm not sure of is how you 'recover' from this situation.

However, given that the computer counters are updated only by the pulse train from the ICDU, I see no obvious reason why the Computer counters in EMEM cannot simply be updated by a program.
21  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 19, 2016, 07:40:44 AM
Maybe the intention is to zero the gimbal angles following the align. Perhaps initial torquing angles could be called up to by the ground. The stable member would be torqued to the required orientation with respect to BRCS or some other requirement. Then the gimbal angles are zeroed. I'm getting the feeling the desired end state is a SM oriented an exact way with reference to BRCS and angles zeroed.

The key seems to be that the SM should be oriented a particular way, not just an essentially random way (as would be the case if it were simply caged, not torqued to any angle then ICDUs zeroed).

Not with reference to BRCS, but rather a common REFSMMAT. During the whole landing and ascent/rendezvous phase the LM and CSM both will have identical REFSMMATs. That really helps with docking.

So during the LM Activation the CSM is holding a specific attitude. The LM then has to torque the IMU to very specific gimbal angles, so that their attitude reference is identical. This is accomplished with the Verb 41. Later the CSM and LM will simultaneously key in V06 N20 to get their IMU angles at the same time. MCC then calculates the angles for a Verb 42 (which are <1) to get their IMUs into complete agreement. Only then (but it can be done at any time) the Landing Site REFSMMAT is uplinked to the LM. At that time the LM has a fine aligned IMU and can find stars etc. without having to use P52. The AOT isn't too accurate, so the docked alignment is better. If the LM is coasting alone for some time, then a P52 becomes necessary.

The V40 undoes the alignment to the docked angles. Of course you can do Verb 42 with all zeros instead, but what is the purpose of the V40? I have the feeling this might be a bug in NASSP or so. Zeroing the ICDUs should not torque the IMU. Well, I don't really know. That's why I asked the question.  ROTFL I'll look into it some more.

Apologies, I was very slack there, yes REFSMMAT Very Happy Ahh I must also apologies for too quick a reading of this issue. The question is specifically on the V40 with LGC activation...ahhh.

I've examined the V40 routine and I can confirm that it does NOT torque the platform. It disables the IMU CDU error counters, clears the AGCs ICDU counters, sets the IMU CDU zero bit.

So in reality it seems the intention here is to have the LM and CM platform Stable Members aligned perfectly together, but to have the CDUs and ICDUs set to zero. I don't quite understand why, this may be needed to keep tabs on any error between them? I'm at a loss for the moment.
22  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 18, 2016, 04:36:51 PM
Well, I'm still confused. All CSM and LM checklists cleary state to perform a V40 N20 after the V41 N20. And after the V40, the gimbal angles are all zeros, regardless of what angles you used with the V41. What am I missing here?

Maybe the intention is to zero the gimbal angles following the align. Perhaps initial torquing angles could be called up to by the ground. The stable member would be torqued to the required orientation with respect to BRCS or some other requirement. Then the gimbal angles are zeroed. I'm getting the feeling the desired end state is a SM oriented an exact way with reference to BRCS and angles zeroed.

The key seems to be that the SM should be oriented a particular way, not just an essentially random way (as would be the case if it were simply caged, not torqued to any angle then ICDUs zeroed).

23  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 18, 2016, 04:00:51 PM
Yeah, on the A15 LM activation checklist on the Virtual AGC page, the V40N20 is actually added by the uploader on top of the document (with a lot of question marks) after the V41. I think it's safe to say it's just a transposition error. The same checklist omits some steps in doing the LGC self-test (namely, doesn't mention resetting the DSKY display after starting the self-test routine).

Agreed it doesn't make a lot of sense.
24  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 16, 2016, 10:59:46 PM
There is something I don't understand about IMU coarse alignments. During the LM activation (but it works just that way in the CSM) you are doing a coarse alignment with V41N20. You then give it the angles for the alignment, e.g. +60.0, +90.0 and 0.0 during the Apollo 12 LM activation. The IMU will then have these angles, the NO ATT light is on and the IMU isn't actually released at this point, I think. The next step is the one that confuses me. With V40N20 the ICDUs are zeroed and the NO Att light is out. The IMU is then operational. But the angles of the IMU always have returned to 0,0,0 at this point. So what is the point of using anything but all zeroes during the V41N20? Shouldn't Noun 20 have the angles used during Verb 41 after this procedure?

Unless I've made a terrible misunderstanding , simply zeroing the ICDUs won't return the platform gimbals to zero, it would have to be torqued back there.
25  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 15, 2016, 04:50:18 PM
Great work as always. I can report having no problems with the new parameters in Apollo 7, on the AGC side. Unfortunately I never did get opportunity to setup a build environment so haven't been able to test the RTCC code changes (but if they are being merged into master I'll test them from the autobuilds).

I have merged everything I worked on for the rotational parameters into the master branch, so the autobuilds have all that stuff. The pad loads in the launch scenarios have the libration vector with the assumption of the values being in radians. The angles are very small, so I don't think it's really possible to verify the scaling in the simulation. I'll trust your AGC code reading abilities on that.  ROTFL

@vrouleau: I know you are around here sometimes. I have taken a look at the LM pad load and it seems you have mostly worked on that. There are a few differences between the pad load in our Apollo 11 scenario and the actual prelaunch erasable load, which can be found here: http://www.ibiblio.org/apollo/Documents/Luminary99PadLoads.pdf Especially the difference in the flagwords confuses me. Do you have any insight into the reasons for the flagword changes? I have searched, but I can't find anything in this forum about it. My goal is to work on some of the padloaded values, that are identical in the CM AGC. Just so that we have a good basis, when we actually get to work on the LM again.

EDIT: Oh now I see, the pad load is from the Apollo 13 pad load source. That won't really work too well though, the default LM AGC version we use is Luminary099. So I think I know what changes have to be done...

I'm confident that the value is in radians, the code is pretty clear on the point and also the routines that use it are fairly compact which allowed me to 'trace' the program flow in my head a little and make sure nothing unexpected happens.

 AGC EMEM values are not the easiest sometimes due to the potential (and sometimes frequent) reuse of the location for other things.
26  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 13, 2016, 11:19:49 PM
I hope my commit today has the magical numbers to make all AGC versions work for Apollo 7-17. There is only a few more things I want to test, then it can be merged into the master branch. As I said, the changes shouldn't have too much relevance for Apollo 7 and 8, even without the correction vectors, and so it won't break anything for these missions. If everything works out we will be prepared for future missions. What I'd like to do, just as a fun challenge, is try to get the P63 Ignition Algorithm to work. That should be possible without working on the Lunar Module itself.

EDIT: This will probably the last commit in the development branch. I have tested the new rotational parameters as good as I could, for Apollo 7 (in Earth orbit) and Apollo 8 and 15 (in lunar orbit). I am fairly confident that it will all work now, but if anybody finds a problem with the new parameters in the launch scenarios, please let me know. Here the final graph for the Apollo 8 mission, with libration vector:

Not too bad, right?  ROTFL

So far it looks like the mission for which the rotational parameters of the Moon work the worst is Apollo 15. But even for that, it is possible to keep the accuracy below 150 meters for all relevant timespans, and close to 0 meters for the LGC at the lunar landing time. But Apollo 15 is so far away, let's think about that in more detail in another year.

Great work as always. I can report having no problems with the new parameters in Apollo 7, on the AGC side. Unfortunately I never did get opportunity to setup a build environment so haven't been able to test the RTCC code changes (but if they are being merged into master I'll test them from the autobuilds).

27  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 03, 2016, 08:13:43 PM
Hmmm....I hate to add more work to your plate, but it does feel to me as if we really do need the ability to generate and ensure the ephemerides we are using are 100% appropriate. Otherwise I feel like we may have a very hard time eventually running down inaccuracies in the navigation.

I send Jarmonik a message, maybe he builds us a LTMFD version with the changed obliquity parameter. It's really only one number that has to be changed and we could still use LTMFD.

I have commited changed navigation stars to the development branch. For the orbital mechanics calculations (including check stars for Maneuver PADs etc.) and also the markers. To me it actually looks like the markers are now closer to the stars as seen in the Orbiter sky. Can someone confirm that? A few markers are now exactly above the stars. Not all though, but that is to be expected. A star like Sirius for example has a fairly large proper motion, about 0.01 in 30 years from the time of the Apollo missions to J2000.

I need to make some time and get setup to build the project. I've been testing the EMEM changes in the AGC only at this point. I need to build so I can try the stars and the RTCC changes.
28  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 02, 2016, 08:09:36 PM
We are ok, if the moon ephemeris being 26km from its actual position is ok. If LTMFD uses the same conversion function from J2000 to BRCS as PAMFD/RTCC MFD, then it also uses the fixed axial tilt of the Earth for the conversion that was used before. The epoch is an input parameter, so the one day change of the epoch and using the epochs of the subsequent AGC versions is no problem. But with the changed obliquity of the Earth a position vector at the lunar distance would be about 26km off. That's just a quick estimate. I can probably come up with something for the RTCC MFD to calculate the ephemerides, if necessary.

Hmmm....I hate to add more work to your plate, but it does feel to me as if we really do need the ability to generate and ensure the ephemerides we are using are 100% appropriate. Otherwise I feel like we may have a very hard time eventually running down inaccuracies in the navigation.
29  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: August 01, 2016, 08:16:02 PM
Again, more excellent work! I guess we have no choice but to test these values with the ephemerides from LTMFD and see how things work out. I will examine the code and see what kind of relationship exists between the ephemeris stuff and the planetary position stuff. My feeling is that we might be okay.
30  Project Apollo - NASSP / Project Apollo - NASSP Development / Re: Virtual AGC on: July 31, 2016, 04:38:52 PM
One thing to note though, is that the GSOP for the LGC suggests uplinking a new libration vector to the LM for a longer stay on the Moon. Not sure if that was actually done, the flight plans suggest that they only uplinked a modified landing site vector, which could do the same job. I'll also do some research into the MIT memos on the Virtual AGC website, maybe there there is some error analysis document about this topic. If we get lower position differences than the actual AGC, then I could be happy with the libration vector values that were used to generate the graphs above.

Excellent analysis (do you do everything in matlab?).

Something I don't really understand, why would the libration vector be for the midpoint? In the case of the LGC wouldn't it make more sense to have it for the expected landing time? Would that be an option?

Pages: 1 [2] 3 4 ... 15
Powered by MySQL Powered by PHP Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!