Meadville Space Center
Welcome, Guest. Please login or register.
June 19, 2013, 12:20:56 AM

Login with username, password and session length
Search:     Advanced search
Project Apollo - NASSP 6.4.3 released!
http://nassp.sf.net
20011 Posts in 1930 Topics by 2250 Members
Latest Member: mikegk
* 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 ... 31 32 [33] 34 Print
Author Topic: Virtual AGC  (Read 60741 times)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #480 on: June 22, 2009, 05:00:34 AM »

Unless I am mistaking those parameters are for Apollo 15 meaning that they do refer in BRCS with different epoch, therefore, those shouldn't be used in Apollo 7 or 8.

LM-7 should be Apollo 13, but of course you're right, the values were just meant as an example of the magnitude of the effect.

Currently, the true rotation axis of the Earth is exactly equal to normal vector of BRCS and in that case AX0 and AY0 must be zero.

Yes, that's what I think, too.

I got the state vector update modification and new configuration file parameters....

Outstanding job again, Jarmo!  Thumbs Up

I did some tests with SV Updates and then checking P21 with Apollo 7 in LEO and Apollo 8 at the Moon and the new values seem to be very precise! Right on spot at the Moon and also the longitude in LEO is fine. There's a small deviation in latitude, but I assume this is because of the spherical vs. Fisher ellipsoid Earth.

BlueDragon8144, would you mind if I commit the changes in PAMFD to CVS? Only GetStateVector and IMFDP31Uplink are changed and a helper function is added, this shouldn't cause any conflicts with your work.

Cheers
Tschachim
Logged

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



View Profile
« Reply #481 on: June 22, 2009, 04:28:11 PM »

Thats fine with me.  I just wanted to make sure I had all the changes so I don't have to cut and paste code over.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1000


jasonims
View Profile
« Reply #482 on: July 04, 2009, 02:08:58 PM »

Ok, I normally steered clear of this forum, even when I was active a while back, but I just went back over what you guys did the past few months, and I want to hug each and every one of you.... or buy you all beers.   Thumbs Up


Rarely have I seen such examples of knowledge and skill so adeptly applied to solve a problem.  My hat goes off to all of you!


... now if I only knew what the hell you were talking about...     Cool

(I jest, but only a bit, so much of what you guys did was beyond me)
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #483 on: July 10, 2009, 02:30:34 PM »

There is still one minor issue related in the Epoch conversion. This is probably not a critical issue but it's a worth of mention. I haven't given much thought for this before but a stars do move pretty quickly, meaning that angular relations between stars are not the same in the Orbiter and the vAGC.  We could expect that some stars have moved as much as 0.01 degrees between 1968 and 2000. There is no need to take any actions for this but let's keep it in mind.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1000


jasonims
View Profile
« Reply #484 on: July 10, 2009, 08:48:44 PM »

back of the napkin calculations have given me the answer of 0.01 degrees being roughly equivalent to 1 pixel in the sextant... I think that's precise enough.   Rolling Eyes
Logged

My Project Apollo Work:
CM Visual
 -VC (~75% complete: texture work beginning again; mesh-78%; texture-70%)
Propulsion Particle Improvements (Focused on S1B right now, BETA 1.0 has been commited)
New Docking Method (~50% complete: research complete; coding partially completed, testing not underway)

Future Work:  (if it's here, it's deemed unnecessary to upcoming release)

Older Work:  (if it's here, it's fair game to whoever wants to improve)
EMS Implementation (committed: minor flaws, but groundwork is there, needs extensive testing)
EMS scrolls (committed: not refined, but usable)
SM Visual (committed: mesh-finished, texture-60%; possibly revisited in future)
J2 Texture (commited: room for improvement)
LRV (committed: mesh-finished, texture-90%; in future a ground up rebuild may be in order, but not on my plans)
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #485 on: July 11, 2009, 02:18:43 PM »

Well, the sextant has a FOV of 2°, with more than 1000px vertical resolution it's more like 5px I think, but I'm happy that we're already looking at such small effects!  Happy

As a quick solution we could use the star markers file "Config\ProjectApollo\Sol_VirtualAGC\Marker\Apollo AGC navigation stars.mkr" for that as it doesn't mark stars, but just positions in RA/Dec.

... and I completely forgot to commit the epoch corrections, sorry, the new config files, scenarios and PAMFD code are committed now.

Cheers
Tschachim
Logged

jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #486 on: July 12, 2009, 01:08:35 PM »

As a quick solution we could use the star markers file "Config\ProjectApollo\Sol_VirtualAGC\Marker\Apollo AGC navigation stars.mkr" for that as it doesn't mark stars, but just positions in RA/Dec.

Ok, I'll make the computations. It's a shame that I didn't realize this when we ware talking about how to deal with the epoch conversion. The plan-a was to alter the star catalogs from vAGC and make the epochs equal. But let's try to avoid that.   
Logged
jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #487 on: July 12, 2009, 02:17:27 PM »

Here's the modified navigation marker data file.

* Apollo AGC navigation stars.zip (1.48 KB - downloaded 78 times.)
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #488 on: July 15, 2009, 06:16:55 PM »

Thanks, file is committed!  Happy

Just to make clear what that means: The star positions are unchanged. The markers now don't point at the star anymore but at the position the star was 1968. That means for optimal precision you need to point the sextant to the center of the marker and not to the star as shown in the attached screenshot.

Cheers
Tschachim 


* ScreenShot00005.jpg (16.85 KB, 606x603 - viewed 224 times.)
Logged

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


nassp.sf.net


View Profile WWW
« Reply #489 on: July 27, 2009, 05:46:14 AM »

Hi Jarmo,

I'd like to forward a question from Ron Burkey (the Virtual AGC founder) from the Virtual AGC mailing list about the star positions as I'm not 100% sure: Is this change because of the movements of the stars w.r.t the sun ("proper motion") and/or parallax shifts due to the position in the Earth's orbit and/or precession of equinoxes and/or nutation of the Earth rotation axis?

If I understand that correctly it's the movements of the stars w.r.t the sun only as we don't do parallax corrections and the last 2 points are compensated by the state vector update?

Cheers
Tschachim
Logged

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


nassp.sf.net


View Profile WWW
« Reply #490 on: July 28, 2009, 04:37:33 AM »

Unrelated to my question Ron managed to find 2 solar ephemeris related memos, perhaps this is interesting:
http://www.ibiblio.org/apollo/Documents/Robertson-SGA-Memo-8-71.pdf
http://www.ibiblio.org/apollo/Documents/Robertson-SGA-Memo-8-71-Addendum-1.pdf
Logged

jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #491 on: July 28, 2009, 02:22:27 PM »

Thanks about the files, I will look at them.

Positions of the stars have changed mostly due to movement (proper motion) respect to the Sun (but I am no expert on this). The star marker file, I posted a few post above, is a computer generated file using the vAGC source code star_table.s as a source and applying the Earth precession matrix to convert the unit vectors to mean earth equator of J2000.  After that R.A. and Dec are computed from the unit vectors. The conversion algorithm is very much the same as the J2000EclToBRCS() except that the Obliquity of J2000 (0.40909280422) is replaced with zero. This should ensure that the stars are in the same positions in the Orbiter and in the vAGC. The only difference should be the Earth precession.

Here's also a development version of LTMFD that can be used to create Lunar and Solar Ephemerides for vAGC.

EDIT: The precession or the nutation of the Earth's rotation axis wouldn't effect in the positions of the stars but only in the coordinate systems where the positions are measured. During the computations of star marker file the precession matrix was applied because the coordiante systems (Epochs) are not the same in the vAGC and in the Orbiter.

EDIT2: I have checked, with two stars, that if I apply the proper motions in the values listed in the new star marker file I got the value listed in the old star marker.

EDIT3:
If I understand that correctly it's the movements of the stars w.r.t the sun only as we don't do parallax corrections and the last 2 points are compensated by the state vector update?
Yes, That would be 100% correct. I hope this is explained well enough.

* Modules.zip (404.42 KB - downloaded 93 times.)
« Last Edit: July 29, 2009, 12:28:06 PM by jarmonik » Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #492 on: July 31, 2009, 07:00:11 AM »

Thanks a lot for the clarification and the modules, a great new feature making things a lot easier!  Thumbs Up

Cheers
Tschachim
Logged

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


nassp.sf.net


View Profile WWW
« Reply #493 on: January 14, 2010, 11:59:34 AM »

The "VAGC CSM Pad Load Worksheet.xls" states that YACTOFF and PACTOFF are set to zero because the virtual CSM has a perfect COG. But that doesn't take in account the fact that there is a hardcoded engine trim offset of -2.15 and +0.95 degrees. Therefore, we have to set the pad loads in opposite directions to compensate the hardcoded offsets. That would make the total engine yaw/pitch trim offset to zero as it was intended from the first place.

Engine yaw/pitch trim angles do effect in initial attitude (See Initial Attutude Subroutine GSOP page 5.3-29)

I revisited this issue and changed it again because I wasn't really happy with the resulting behaviour: As Jarmo explained correctly with these trim angles set, the CSM nose (Apollo x-axis / Orbiter z-axis) is pointing to the desired initial thrust direction at ignition. But again this isn't the actual initial thrust direction because now the SPS is pointing to the direction of the trim offset. Even worse, because of the offset the CSM isn't stable at ignition and the TVC autopilot has to move the SPS back to zero angles as this is still the setting where the CSM doesn't change it's attitude. This leads to confusing and seemingly wrong FDAI attitude error readings. So I changed the configuration again to achieve the following requirements:

  • The V48 trim angles shall match the historically used values. Currently we don't know these values, but surely they weren't used to compensate the hardcoded angles but to provide additional trimming, so for now the trim angles shall be zero.
  • Before the burn the CSM shall be orientated so that the SPS is pointing in initial thrust direction.
  • The spacecraft shall be stable / not changing its attitude, when the SPS is pointing in the trim angle position (i.e. 0, 0), because this is what is meant by trimming and what the VAGC expects.

So I set the trim angles back to 0, 0 and introduced a hardcoded engine trim offset of -2.15 and +0.95° in the SPS itself, just like the real thing. Also, to achieve the 3rd point, I moved the position of the SPS engine off-center so that the CSM doesn't change it's attitude despite the hardcoded offset angles. Now everything's fine in Virtual AGC mode.  Happy

Important: I did the SPS direction/position offset in Virtual AGC mode only, because with these offsets the SPS doesn't accelerate the CSM along the x axis anymore, but along the offset direction, which most probably confuses burns done by external tools like IMFD etc., which still should still work fine in Quickstart Mode.

Cheers
Tschachim
Logged

jarmonik
Full Member
***
Posts: 130


View Profile Email
« Reply #494 on: January 20, 2010, 06:47:49 AM »

Important: I did the SPS direction/position offset in Virtual AGC mode only, because with these offsets the SPS doesn't accelerate the CSM along the x axis anymore, but along the offset direction, which most probably confuses burns done by external tools like IMFD etc., which still should still work fine in Quickstart Mode.
A vessel/engine orientation is not a factor in a dv calculations. Also the autoburn will orientate the engine in a desired thrust direction. Therefore, this modification shouldn't effect in IMFD nor LTMFD.

But again this isn't the actual initial thrust direction because now the SPS is pointing to the direction of the trim offset.
I don't quite understand. I thought this would set the engine axis parallel with CSM axis ??  Not the other way around.

Even worse, because of the offset the CSM isn't stable at ignition and the TVC autopilot has to move the SPS back to zero angles as this is still the setting where the CSM doesn't change it's attitude.

I don't understand what, exactly, is changing attitude ?  Is the vAGC trying to simulate or estimate something related in attitude during SPS burn ?
Is the COG of CSM changed lately from the vAGC or from the Orbiter ?

So I set the trim angles back to 0, 0 and introduced a hardcoded engine trim offset of -2.15 and +0.95° in the SPS itself, just like the real thing. Also, to achieve the 3rd point, I moved the position of the SPS engine off-center so that the CSM doesn't change it's attitude despite the hardcoded offset angles. Now everything's fine in Virtual AGC mode.

You mean that the SPS is now gimballed from the Orbiter version of the CSM to match the real thing ?  Of course, that's a lot better way to solve the problem. But if there were a need to shift the engine, that would indicate that the COG of the CSM in the Orbiter lies in the main axis.
Logged
Pages: 1 ... 31 32 [33] 34 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!