Meadville Space Center
Welcome, Guest. Please login or register.
July 08, 2020, 06:53:58 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
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)
| | | |-+  ApolloTelemetryMFD
« previous next »
Pages: 1 2 [3] 4 Print
Author Topic: ApolloTelemetryMFD  (Read 11498 times)
schneci
Project Team Member
Full Member
****
Posts: 31


View Profile
« Reply #30 on: November 15, 2007, 03:29:48 PM »


I checked by V82 and I have got negative number too. Ashamed I modified the code and the new version is working better, because V82 show correct numbers. Yes However I think the State Vector Update xls is giving wrong solution, because the earlier version of ApolloTelemetryMFD is based on the xls rule. No



Hi schneci, good work! Thumbs Up
Allthough the worksheet is useless now for SV update, could you explain the modification to your code in order to see where the problem was.
I'd like not to make similar errors with EOCA.


Hi Christophe,

The following code show the calculation of LHLV transformation:
Code:
// tranform the position vector from orbiter reference to local horizon coordinates
g_State.Vessel->GetRelativeVel(g_State.Vessel->GetGravityRef(),RVEL);
g_State.Vessel->GetRelativePos(g_State.Vessel->GetGravityRef(),RPOS);

t = getRotationMatrixY(0.0);
t = multiplyMatrix(getRotationMatrixZ(0.0), t);
t = multiplyMatrix(getRotationMatrixX(0.40927971), t);
RPOS = multiplyMatrixByVector(t, RPOS);

// tranform the velocity vector from orbiter reference to local horizon coordinates
t = getRotationMatrixY(0.0);
t = multiplyMatrix(getRotationMatrixZ(0.0), t);
t = multiplyMatrix(getRotationMatrixX(0.40927971), t);
RVEL = multiplyMatrixByVector(t, RVEL);



The gamma angel is 23,45 deg and alpha, beta is 0 deg



Quote
One last question. Do you plan to go further with other updates: external delta V, landing site and so on...?
Would be great!

Yes, I plan that functionality, but step by step. First of all I would like to finish the State Vector and REFSMMAT Update.

Best regards,

George
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #31 on: November 15, 2007, 04:39:40 PM »

Hi George,

I would like to get your code into our current code tree so we can begin basic bug testing and then get it into the next beta modules pack.

I'm not against downloading it separately, but it would be nice to get it as integrated into our beta packs as possible so as to get feedback from users.  I would be willing to help integrate it into the existing MFD (probably the best way to do this) but I think it would be best if the code was at least already in the cvs tree.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #32 on: November 17, 2007, 03:51:35 AM »

Hi Schneci!
As far as I can see, the computation is the same than in the SV update spreadsheet, so I wonder why there is a bug with it.
Anyway, thanks and keep up your work. Thumbs Up
Logged
schneci
Project Team Member
Full Member
****
Posts: 31


View Profile
« Reply #33 on: November 17, 2007, 07:48:45 AM »

Hi Schneci!
As far as I can see, the computation is the same than in the SV update spreadsheet, so I wonder why there is a bug with it.
Anyway, thanks and keep up your work. Thumbs Up

Hi Christophe,

My problem was in "State Vectors" spreadsheet at E18 cell (see following formula) by minus sign before at RN x component:

=-'Orbiter to AGC'!B25

My opinion an other problem was in "Orbiter to AGC" spreadsheet at B21,22,23 and D21,22,23 cells (see following formula) by the RN and VN component order and the minus signs:

='State Vectors'!B18      ='State Vectors'!F2
='State Vectors'!B20      =-'State Vectors'!F4
=-'State Vectors'!B19      ='State Vectors'!F3

I think the appropriate order is B18, B19 and B20 or F2, F3 and F4.

If you can see following excel sheet matrix, the minus and plus signs are different places, then in my matrix:

         COS(C1)            0             -SIN(C1)
Q1      0                     1             0
         SIN(C1)             0             COS(C1)

         COS(C2)         SIN(C2)       0
Q2     -SIN(C2)         COS(C2)      0
         0                      0               1

        1                       0             0
Q3    0                     COS(C3)    SIN(C3)
        0                    -SIN(C3)    COS(C3)


But may be, I made mistake.

Best regards,

George
« Last Edit: November 17, 2007, 03:11:09 PM by schneci » Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #34 on: November 18, 2007, 07:48:25 AM »

='State Vectors'!B18      ='State Vectors'!F2
='State Vectors'!B20      =-'State Vectors'!F4
=-'State Vectors'!B19      ='State Vectors'!F3

Well, I understand the problem.
You simply have opened the wrong spreadsheet. Wink

The story is the following:

The 'vAGC State Vector. xls', located at \Doc\Project Apollo - NASSP\Check List\G&C checklist was written about 2 years ago by irnenginer in order to get the vAGC working in NASSP; previously, the vAGC simply was nothing but a curiosity and thanks to irnenginer for having shown that the vAGC could reliably work with the simulation.
From this point I was convinced that the vAGC was the only way to get NASSP as a "true" simulator instead of a simple orbiter addon. (I still think so today despite some people who prefer the simple AGC, just a question of opinion).
So I started to work on the entire GNC checklist and tested during 6 monthes all the vAGC verbs, noon and programs to see what was working and what wasn't. Running through the P27 I worked on my own spreadsheet in order to get the other updates to be available, and started from the irnenginer spreadsheet. I noticed that there was a mistake into the transformation maths (a slight mistake in the frame of reference) and corrected it.
So I build a new spreadsheet named 'CMC update.xls' and put it into a the new folder I created for the GNC checklists at: \Doc\Project Apollo - NASSP\Check List\G&C checklist\colossus_1A_249
If you open this spreadsheet you will see that the correction you mentionned are already done.
You'll see that there are 3 other updates available too, and with respect of the GSOP numbering:

2_external delta V:
to load some computed maneuvers into the AGC memory via P27 instead of P30. In that way, the maneuver is stored and when you further run the P30 in order to perform the maneuver, the datas are already there and dispayed. In this case you only have to check the values and confirm them by "PROing" at each step. However you may update them by changing the values, as usual with the standard V21/24/25 procedure.

5_Retrofire External Delta V:
Same as above with the addition of the landing site coordinates.

6_Entry: a way to load the landing site coordinatres in order for the DSKY to be available for deorbit and entry. If you don't do this update you cannot run the P60's programs and won't be able to go back to earth.

All these updates and their corresponding programs work (at least they worked last year) and I hope that the changes that have been made since that time have not broken anything. I fear that the worked that have been made on the CM RCS, for the use of the simple AGC ( Yuck! Two Cents) for reentry (OK I'm just joking... Wink), has confused the vAGC, but I didn't do any test with it since. So...

I was not able to build the other updates, especially the REFSMMAT ones because there was something in the GSOP I did not understand, related to the format of the numbers for them to be accepted by vAGC.
I remembered having openned a thread on this forum about that problem and having no answer, cause in fact, by theses days, nobody cared about the CMC updates.
It's a shame because the update is the most important key for the vAGC to work properly on the sim.

So, you probably not realize how I'm glad to see you in this project because you seem to be convinced of the importance of that, and with some real mathematical and coding ability.  Happy Thumbs Up

For example: You developped a very realistic SV update features, like in real by switching the update telemetry to "Accept" and the use of the MFD that replaces the ground controller task. That's exactly how I consider the simulator:
- Real procedures in the vessel: vAGC, systems handlings (EPS, ECS...) and so on...
- Orbiter MFD's or spreadsheets to perform the tasks that are done by the ground in real life.

So if you go further with the updates features, we would probably be able in a near future to get more available vAGC programs: if for example you put the "other vehicle SV update" on the sim, with the use of both the MFD and the VHF ranging swithch (instead of the telemetry) I'm pretty sure that all the RDV programs would work properly (P20, P34, P35, P38, P39 and probably the P70's)

Honnestly, the project seems to be at a standstill by now, at least as far as the vAGC is concerned so I hope that you and Lassombra will give it a new breath.
If irnenginer manages to solve the moon state vector problem I see no more barrier for the vAGC to get us on the moon an back to the earth safely (hopefully before this decade is out...   Excited!)
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #35 on: November 18, 2007, 04:48:06 PM »

If "CMC Update.xls" does the same as "VAGC State Vector Update.xls", but without bugs and with additional features, should we remove "VAGC State Vector Update.xls" to avoid that confusion / problems?

I made a new version of ApolloTelemetry MFD, which includes not only state Vector update, but REFSMMAT update. I use for calculation of reference matrix the definition (6.3.16) and the equations (6.3.18) in "R-577-sec5-rev4-5-6.pdf" 5.6.3.3 REFSMMAT Transformations chapter.

My question is: How can I test by Virtual AGC this new version? Witch Program and routine have to use to see how works my code?

I hoped Christophe or irnenginer is going to answer that, I'm not sure if I understand that correctly, but I'll try, please correct me if I'm wrong:

You're calculating the nominal REFSMMAT for the present time, i.e. the REFSMMAT with which the spacecraft orientation matches the current LVLH system with (0, 0, 0) gimbal angles. You upload the REFMMAT, but you don't realign the IMU, so the orientation is "messed up" after that and you need to run a P52 "REFSMMAT" to realign the IMU.

This is the same as P52 "nominal" does if you enter the current GET, so you can test if the spacecraft has the same orientation with the same gimbal angles using both methods. Also you could add the feature to be able to enter a GET in the MFD and calculate/upload the nominal REFSMMAT for a future GET. Then you do a P52 and after that you orient the spacecraft to (0,0,0) gimbal angles. When the entered GET is reached, the spacecraft needs to match the LVLH system (Surface MFD/HUD).

Cheers
Tschachim
Logged

Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #36 on: November 18, 2007, 06:27:52 PM »

This method sounds good for me.

What I don't understand in GSOP R-577-sec2-rev2, chapter 2.1.5.2 and 2.1.5.3 is the difference between the"desired REFSMMAT update" and "REFSMMAT update". Bangs Head
Any idea?
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #37 on: November 18, 2007, 08:12:04 PM »

What I don't understand in GSOP R-577-sec2-rev2, chapter 2.1.5.2 and 2.1.5.3 is the difference between the"desired REFSMMAT update" and "REFSMMAT update".

That's interesting, I never read that section. I don't know, but I'd guess that "REFSMMAT update" updates the REFSMMAT directly (messing up the orientation as forementioned) and "desired REFSMMAT update" doesn't change the REFSMMAT directly, but the uploaded REFSMMAT is the preferred REFSMMAT used in P52 "preferred" (without messing up anything, just run P52 "preferred" after the upload). This needs to be checked, of course, I never tried it.

Cheers
Tschachim
Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #38 on: November 18, 2007, 11:56:56 PM »

2.1.5.2 This is for inputing a "preferred attitude" REFSMMAT
2.1.5.3 Is for updating the REFSMMAT directly

I was not able to build the other updates, especially the REFSMMAT ones because there was something in the GSOP I did not understand, related to the format of the numbers for them to be accepted by vAGC.
I remembered having openned a thread on this forum about that problem and having no answer, cause in fact, by theses days, nobody cared about the CMC updates.
It's a shame because the update is the most important key for the vAGC to work properly on the sim.

Sorry I missed that thread.  Embarassed I have that pretty well understood.

If "CMC Update.xls" does the same as "VAGC State Vector Update.xls", but without bugs and with additional features, should we remove "VAGC State Vector Update.xls" to avoid that confusion / problems?

That is probably for the best.

I made a new version of ApolloTelemetry MFD, which includes not only state Vector update, but REFSMMAT update. I use for calculation of reference matrix the definition (6.3.16) and the equations (6.3.18) in "R-577-sec5-rev4-5-6.pdf" 5.6.3.3 REFSMMAT Transformations chapter.

My question is: How can I test by Virtual AGC this new version? Witch Program and routine have to use to see how works my code?

Testing these two can be a real pickle. For the State Vectors I would Suggest the Following:

Perform (as Tschachim suggests) perform a P52 to a nominal orientation. Orient the Spacecraft to Gimbal Angles (0,0,0) and see if you are pointed prograde at the GET you entered by comparing the spacecraft orientation to the orbit HUD. I would then perform a P21 and compare the LONG and LAT to what is reported in the SURFACE MFD at the GET you specified. The numbers should match closely, but I have never gotten them to match perfectly.

FOR REFSMMAT:

I think the best way to verify a new REFSMMAT is to create one that points the stable member origin to a known point (like a star) and do a P51 and then P52 and verify that the pointing at the star gets you gimbal angles (0,0,0).


Finally, I have not been able to spend much time on this over the summer. I hope that I can now get back into it. The moon state vector is solved and is working well for Apollo 7. With that in mind it may be good to start working on Apollo 8. There are some other things too I have been working on which I will report on in the next day or so.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #39 on: November 19, 2007, 04:59:58 AM »

Finally, I have not been able to spend much time on this over the summer. I hope that I can now get back into it. The moon state vector is solved and is working well for Apollo 7. With that in mind it may be good to start working on Apollo 8. There are some other things too I have been working on which I will report on in the next day or so.

That is a good news! Happy
Do you think we will be able to load any moon vector for any mission by using a spreadsheet?
That would be great.

As far as the desiored REFSMMAT update versus REFSMMAT update is concerned, I've understood things differently but I'm probably wrong: I thought the REFSMMAT update was a load of a new REFSMMAT indeed, but the desired update was the load of a new and specific matrix that transform the current REFSMMAT by a matrix product.
Because at the beginning I thought that the "preferred" option did not erase the current REFSMMAT. And that's what I wrote on a post that is now on the WIKI. But the maneuvers I performed with P40 in preferred REFSMMAT orientation showed me that the preferred REFSMMAT would replace the currrent one.
I mean that: if you have a given REFSMMAT then perform a P52 option 1 (preferred) and then you make a new P52 but this time in option3 (current REFSMMAT) the REFSMMAT does not come back to the original one. You will see that you still are with the preferred one that is now the current one.

Would be interesting to have results for some other testing people.

EDIT:
It seems that there is a way to load a preferred REFSMMAT into the AGC in an other way that by the P40. In the Apollo 8 flight transcript it's written that the preferred REFSMMAT for the LOI burn was loaded about 8 hours before the LOI itself and Borman tested it with a sextaznt star check a few hours later and far before coming on the far side of the moon.
If you read the verb list in 1_CMC general checklist there are are two verbs:
V76:Set Preferred ATT Flag
V77:Reset Preferred ATT Flag
I never managed to get it working. By the way that are the subjects of the thread I mentionned having posted one year ago with no answer.
GSOP sec4-rev6 says in P52 chapter that the computer checks wether the preferred att flag is set or not. If it's set it displays option 1 (preferred) in first and if not option 2 (I remember...)
And in P40 chapter it says that the programs automatically set this famous Att flag;
So, I understand that the preferred att flag has to be loaded previously and then activeted by the crew with V76 if you want to get the option activated. If not the att flag would be set by P40 at the last limit, the computations made with the help of the values previously loaded in the prethrust program (P30).

Just thoughts, of course

« Last Edit: November 19, 2007, 05:16:15 AM by Christophe » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #40 on: November 19, 2007, 09:39:50 AM »

That is probably for the best.

Done!

There are some other things too I have been working on which I will report on in the next day or so.

The position of the Sun would be nice...  Happy

Cheers
Tschachim
Logged

irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #41 on: November 20, 2007, 10:55:51 AM »

Do you think we will be able to load any moon vector for any mission by using a spreadsheet?
That would be great.

Unfortunately a spreadsheet solution will not work in this case. Excel can only calculate a 6th order polynomial when a 9th is what is needed.

V76:Set Preferred ATT Flag
V77:Reset Preferred ATT Flag

These verbs are actually associated with rendezvous P20. One orients the SC for optics and VHF antenna preferred attitude to the target SC. The other points the COAS at the target SC.
Logged
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #42 on: November 20, 2007, 12:11:46 PM »

V76:Set Preferred ATT Flag
V77:Reset Preferred ATT Flag

These verbs are actually associated with rendezvous P20. One orients the SC for optics and VHF antenna preferred attitude to the target SC. The other points the COAS at the target SC.

So that's confirm that our AGC version known as colossus 1A-249 is not exactly the colossus 1A-249. This is one of the slight differences. I'll update the checklist according to that.
Logged
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #43 on: November 21, 2007, 08:06:40 PM »

So that's confirm that our AGC version known as colossus 1A-249 is not exactly the colossus 1A-249. This is one of the slight differences. I'll update the checklist according to that.

I'm not sure if that is the case, I got that info from R-577. I can say that V76,77 change PRFTRKAT #  BIT 10 FLAG 5 and the preferred attitude flag for IMU orientation is PFRATFLG # Bit 4 FLAG 2, from the source listing.
Logged
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #44 on: December 07, 2007, 03:05:44 PM »

I'm not entirely sure what is going on with this, but when running the apollo 7 agc launch scenario, I run into a few problems pretty quickly after using the telemetry mfd.

First and foremost, immediately after entering orbit, I'm able to do a alignment no problems.

I do a state vector update with either the mfd or the spreadsheet and then I get issues with alignments, bad marks, it thinking a star is within available field of view when it isn't.  More and more problems.   Not the least of which is that it thinks stars are quite away from where they really are.  It has no problems pointing to the SIV before the sv update, after, it can't find it.  I run a SV update on both vehicles and I can find it again, but I suspect that's due to them having the same inaccuracy.  I honestly couldn't tell you what the problem is, but I noticed before launch, no matter what I did, the AGC is behind the PAMFD countdown by exactly 2 seconds, every time.  I doubt those two seconds are anything to worry about, but they could be symptoms of a greater problem.
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
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!