Meadville Space Center
Welcome, Guest. Please login or register.
July 11, 2020, 10:42:37 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)
| | | |-+  Auto vAGC State Vector Update
« previous next »
Pages: 1 ... 7 8 [9] 10 Print
Author Topic: Auto vAGC State Vector Update  (Read 32997 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #120 on: August 29, 2008, 08:15:44 AM »

Does this issue occur only with auto SV update MFD or even with manual CMC update using the excel spreadsheet?

I only tested the Auto SV Update.
Logged

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


View Profile Email
« Reply #121 on: August 29, 2008, 10:26:10 AM »

Ok I'm too busy to check the SV update right now but I read again some post above on this thread. I'm pretty sure the issue is from the way the MFD takes the datas. The SV must be the one for a specific time. No matter the time it takes to upload it into the memory. Isn't it possible to pick up the datas just like the scn editor does, in a frozen instant?
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #122 on: August 29, 2008, 10:56:07 AM »

Isn't it possible to pick up the datas just like the scn editor does, in a frozen instant?

This is what we're doing already, i.e. to pick up all the data including time in one time step, but a comparison with the Excel/Scn Editor version would be interesting as there might be small differences between the two ways.

Cheers
Tschachim
Logged

Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #123 on: September 09, 2008, 01:02:53 PM »

As it looks like nobody is really working on this problem, I took a look the last days. I found 2 bugs in the latest version, the bigger one is that oapiGetPlanetObliquity gets the planet handle as argument (not the name) and the result is in rad, not deg. The smaller one was the use of abs() with the mission time instead of fabs(), which rounded the mission time to the next second. I fixed both bugs in CVS, testers please do a CVS update, the SV before these fixes was way off.

After that's I did more tests, now using P21 (geographic position) and P47 together with N62 to get inertial velocity, local vertical velocity and height. I also did tests with re-uploading the same SV several times within a couple of minutes to check for problems with the upload itself and consistancy within the AGC. As far as I can tell, it looks like the upload itself is working fine, also the AGC gives the same results with the same state vector, but the calculated state vector in the MFD seems to be off up to about 10km in position, the error varies each upload, I still have no clue why.

To avoid duplicate work I would like to ask if someone else is looking at that problem right now, also it would be great if someone of the AGC experts around here can take a look at ProjectApolloMFD::GetStateVector() as I don't know if the calculations there are correct. If nobody else is going to look at that, I'll try harder to get this fixed...  Happy

Cheers
Tschachim
Logged

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



View Profile
« Reply #124 on: September 11, 2008, 11:09:16 AM »

I managed to have a few minutes last night to take a look at this finally. The math in GetStateVector looks good but I will study it some more. C++ does a horrible job at math so it is a bit hard to figure out whats going on. The resultant state vector of an update also looks good, to be honest I think we are on the money.

I think I can explain why you see a 10km offset. There is still some inaccuracy in the AGC padloads that determine the translation between the "Basic Reference Coordinate System" (ie state vectors) and the "Earth Fixed Coordinate System" (ie surface coordinates).  There are 3 parameters for this AZO, -AYO, and AXO. There may also be some difference in the coordinate systems that orbiter uses vs that of the AGC. The total error is in the area of 10s of km.

Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #125 on: September 11, 2008, 12:10:09 PM »

The math in GetStateVector() was taken straight from the excel sheet for manual state vector update, which is why I asked to see if the excel sheet got the same results to see if it was an error in my programming. 
Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #126 on: September 12, 2008, 12:18:54 PM »

Finally got around to doing some testing, so I did both manual and state updates using the same data, give or take a few milliseconds.  What I did was start up a Auto SV update, but pause at just as the data starts coming in, so as I can input the date and state vectors in to the cmc update excel sheet.  Then, I unpause, let it go, and enter in V82 to get the orbit parameters.  After that, I did the same thing using the excel sheet numbers.  Then I repeated it 5 more times.

                MFD               Auto             Manual
Test 1   153.7x124.5   155.8x128.6   156.6x127.2
Test 2   154.5x124.6   164.5x130.8   165.2x129.7
Test 3   155.5x124.5   168.3x125.1   168.2x124.2
Test 4   156.5x124.1   174.2x137.6   174.4x137.0
Test 5   157.4x123.7   149.2x117.0   149.5x116.4
Test 6    158.7x122.8   167.7x127.4   168.4x127.2

Just something I was looking for when i didn't have excel.  But it looks like the upload is fine.  It's just either the math or the agc portion thats causing the errors.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #127 on: September 12, 2008, 07:02:48 PM »

Thanks for the replies, I think I found it, there seems to be a bug in the conversion of negative numbers to the octal values, I'll do more tests and will post later...

Cheers
Tschachim
Logged

bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #128 on: September 12, 2008, 08:38:04 PM »

To clarify, when converting negative decimal numbers to octal for the agc, would you do this?

Code:
|-0.530688379*2^14| = 8695
8695 to binary = 0b 010 000 111 110 111
invert =         0b 101 111 000 001 000
bin to oct =     0o  5   7   0   1   0
« Last Edit: September 12, 2008, 08:54:51 PM by BlueDragon8144 » Logged
bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #129 on: September 13, 2008, 05:00:25 AM »

Found the problem.  Wasn't an error in converting from decimal to octal.  The problem actually stemmed from the excel sheet.  I was using values from Fabrizio Bernardini and Christian Bucher's SV analysis and found numbers that just did not match up.  The high components were spot on, but it was the low components that had a problem, specifically low components of negative values, and I traced it to the fmod routine, and fiddled around to see if I could find the error, which I did find one.

The equation is not -fmod(value, 2^-14), but it is actually
-fmod(-value, 2^-14), or -fmod(abs(value), 2^-14)

That resulted on numbers that were spot on with the SV analysis, and once in orbiter, I did 5 tests, and the parameters matched with an error of +/-0.1km.

I've commited the changes, as well as the excel changes.


 
« Last Edit: September 13, 2008, 05:11:55 AM by BlueDragon8144 » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #130 on: September 13, 2008, 07:27:22 PM »

Yeah, that does the trick, works pretty well, for my part it's fine now!  Thumbs Up  Thumbs Up  Thumbs Up

I got your changes of the excels with the CVS update, but not of the code, could you check that?

There are 3 parameters for this AZO, -AYO, and AXO.

While we are talking about that, AXO and AYO is Earth precision and nutation and as far as I know Orbiter doesn't simulate that, should we use 0 for both (I didn't try that yet)? Do we need new pad loads for the position of the Moon and the Sun in this case (Sun pad loads for Apollo 7 are still missing, it would be great if you can take a look at that if you have some time left  Happy ) ?

Sorry to bothering you with all these questions, but I'd like to have a "baseline configuration" for that stuff for Apollo 7 rather soon as I hope we can begin with flight tests for the release soon (the Earth orbit at insertion and the S-IVB on orbit still needs fixing though).

Cheers
Tschachim
Logged

bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #131 on: September 13, 2008, 07:48:21 PM »

Sorry, I guess it didn't go through for some reason. Bangs Head
It's now up on CVS. 
Logged
irnenginer
Project Team Member
Sr. Member
****
Posts: 271



View Profile
« Reply #132 on: September 14, 2008, 10:40:06 PM »

While we are talking about that, AXO and AYO is Earth precision and nutation and as far as I know Orbiter doesn't simulate that, should we use 0 for both (I didn't try that yet)? Do we need new pad loads for the position of the Moon and the Sun in this case (Sun pad loads for Apollo 7 are still missing, it would be great if you can take a look at that if you have some time left  Happy ) ?

Sorry to bothering you with all these questions, but I'd like to have a "baseline configuration" for that stuff for Apollo 7 rather soon as I hope we can begin with flight tests for the release soon (the Earth orbit at insertion and the S-IVB on orbit still needs fixing though).

I am not sure if they should be zero or not. while they may not be modeled in orbiter the reference will be different from 1968 so I would assume it will need something in here so it works out. These parameters only deal with earth tilt variation so it only impacts the accuracy of the translation between state vectors and earth referenced surface coordinates and vise versa. Operationally the only impact is using P21, P22 and at liftoff to determine the initial state vectors.  I will work on it.

I feel bad about the negative number thing. I saw that bug six months ago and had fixed it in a new spreadsheet version but had held onto it while I was looking into TVC DAP issues (which still exists) and then got sidetracked with some life stuff and summer. With summer falling behind us I think I can be more int the game and not leave you guys hanging. The spreadsheet also includes Sun Data for Apollo 7.  I will post a thread that will discuss all the remaining vAGC issues I am aware of.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #133 on: September 15, 2008, 04:57:30 PM »

It's now up on CVS. 

Thanks, the changes arrived well. I also committed two more cosmetical changes, the telemetry checklist in the MFD is now formatted like the Checklist MFD and I removed the mission specific "CMC Update" excels and added the Apollo 7 & 8 values to the generic one, with Apollo 7 as default values for easier maintenance, I hope this is fine for all.

irnenginer, don't feel bad too much, at least we guys learned more about the AGC.  Happy

I did some tests with P21 and AXO=AYO=0, but I don't see any substancial improvements (always about +/- 0.1), so I think it's up to you. Also please don't worry too much about getting everything ready like TVC for example, every small improvement is important in my point of view, so I'd be happy if you commit what you have and we improve it step by step.

Cheers
Tschachim
Logged

bluespace88
Project Team Member
Full Member
****
Posts: 241



View Profile
« Reply #134 on: September 15, 2008, 06:09:01 PM »

yeah, don't feel bad about it.  We did learn more about the AGC and the math behind it Happy

the changes are fine with me.  It's better to have it all in one file rather than have multiple, especially if only the launch date changed.

Also, wondering, what else needs to be done before releasing 7.0?  I'd like to work on some more stuff.
Logged
Pages: 1 ... 7 8 [9] 10 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!