Meadville Space Center Forum Index Meadville Space Center
Know the future through the past
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Virtual AGC
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Meadville Space Center Forum Index -> Programming
View previous topic :: View next topic  
Author Message
irnenginer



Joined: 29 Jan 2006
Posts: 64

PostPosted: Sat Feb 25, 2006 5:41 am    Post subject: Reply with quote

Putting values both for delV and gamma deem to confuse it. Try 0 for delv and -5.1 for gamma. The program should determine the minimum burn to provide that gamma value. It has worked for me consistantly. In fact the burn that is performed seems to put the CSM in the attitude for SM jet as part of the burn, with the nose down at an angle to the horizon.

I run P37 at about 30min before the burn
Back to top
View user's profile Send private message
Christophe



Joined: 09 Feb 2005
Posts: 280
Location: France

PostPosted: Sun Feb 26, 2006 8:28 am    Post subject: Reply with quote

irnenginer wrote:
Putting values both for delV and gamma deem to confuse it. Try 0 for delv and -5.1 for gamma. The program should determine the minimum burn to provide that gamma value. It has worked for me consistantly. In fact the burn that is performed seems to put the CSM in the attitude for SM jet as part of the burn, with the nose down at an angle to the horizon.

I run P37 at about 30min before the burn


hi irnenginer!

I'm being studying both P37 and DAP procedures for reentry.

-VPRED: according to A15DELCO, I agree with you: 0 is the number you have to enter for max delta V (F 06 60) in order for the CMC to compute the min delta V for the burn. That save fuel. More details are explained in A15DELCO P37 assumption 2.

-Gamma value: It's the reentry angle at E/I (400kft). your value, -5.1 , seems to be very high for me as far as you enters from earth orbit.
From lunar entry nominal angle is 6.50, it's very easy to confirm this value with any doc file, but for earth orbit entry, it's more difficult.
Looking at "Apollo by the numbers" pdf doc file, report entry flight path were:
-2.0720 for Apollo 7
-1.74) for Apollo 9.
I'll try with a mean value of -2.0 from earth orbit.

An other issue seems to be the TIG setting. As I understand you have to enter it at the beginning (F 06 33). I will try to use an orbiter MFD, may be IMFD with base approach program to compute a burn for entry targeting a specified landing site with appropriate value. This will give me a predicted efficient time for the maneuver I will further enter in P37 V06 N33 and see if this works.
The problem is that with the current beta modules I'm unable to use a saved scenario. Each time I try I experienced a "jammed CMC" that does not accept any entry. So I have to relaunch a new mission each time. Very boring...

Cheers...
Back to top
View user's profile Send private message Send e-mail
Tschachim



Joined: 26 Nov 2004
Posts: 1272

PostPosted: Sun Feb 26, 2006 3:30 pm    Post subject: Reply with quote

Christophe wrote:
The problem is that with the current beta modules I'm unable to use a saved scenario. Each time I try I experienced a "jammed CMC" that does not accept any entry. So I have to relaunch a new mission each time. Very boring...

Embarassed Sorry, then I'll make new beta modules ASAP, propably tomorrow. With the current CVS version saving/loading works fine for me, but movieman reported bugs like this, so we can check that then. By the way: Did you try to build the current CVS version with VS 2005 Express?

Cheers
Tschachim
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Christophe



Joined: 09 Feb 2005
Posts: 280
Location: France

PostPosted: Sun Feb 26, 2006 3:47 pm    Post subject: Reply with quote

In fact I've managed to reuse some saved scenario by rewriting the environment setting: it's just because the quick save automatically reset the environment to project Apollo/sol instead of project Apollo/sol_VirtualAGC.
But that doesn't always fix the problem. Sometime the scenario works well and sometime not. I don't know exactly why Shocked
Quote:
By the way: Did you try to build the current CVS version with VS 2005 Express?

I 've send you a mail a few days ago with the last error and warning messages I have when I try to build. Did you get it?
It's better now cause I can build somme dll's but not the entire project.
And as you ever know "C++" means "Chinese ++" for me Wink
Back to top
View user's profile Send private message Send e-mail
Tschachim



Joined: 26 Nov 2004
Posts: 1272

PostPosted: Mon Feb 27, 2006 2:44 pm    Post subject: Reply with quote

Christophe wrote:
In fact I've managed to reuse some saved scenario by rewriting the environment setting: it's just because the quick save automatically reset the environment to project Apollo/sol instead of project Apollo/sol_VirtualAGC.

Thanks for pointing that out, there was a bug in the config file, it's fixed now.

Quote:
I 've send you a mail a few days ago with the last error and warning messages I have when I try to build. Did you get it?

Last mail I got was from Feb. 10, I did some changes and answered at Feb. 21, but my email account was broken at the weekend. Looks like dseagrav did also some changes because of more recent compilers, perhaps it's a good idea to update the sources, re-try and mail me again.

I have a horrible flu, I fear beta modules have to wait a little bit... Sad

Cheers
Tschachim
Back to top
View user's profile Send private message Send e-mail Visit poster's website
movieman



Joined: 25 Nov 2004
Posts: 1018

PostPosted: Mon Feb 27, 2006 2:59 pm    Post subject: Reply with quote

I know we don't save absolutely all Virtual AGC state information in the scenario, but I believe we save as much as we should have to: it's possible there's something I've missed which doesn't work properly when it's zeroed on reloading the scenario.

Working or not working seems pretty random for me.
Back to top
View user's profile Send private message
Swatch



Joined: 15 Feb 2006
Posts: 262
Location: Cincinnati, Ohio

PostPosted: Sat Mar 04, 2006 4:13 pm    Post subject: Reply with quote

I meant to ask if the goal eventually was to combine Virtual Apollo with the rest of Project Apollo. (need this information for the Progress Thread)

The alternative is to leave them as two seperate things that use two seperate scenarios. This seems quite inefficient however. Anyway, curiosity.
Back to top
View user's profile Send private message AIM Address
Christophe



Joined: 09 Feb 2005
Posts: 280
Location: France

PostPosted: Mon Mar 06, 2006 10:01 pm    Post subject: Reply with quote

The state that has now reached the virtual AGC asks the question of the navigation tool we could use in NASSP.
The old version 6.4.2 (that seems very far away from now) could easily work with any MFD you want. I know that some prefered trans X and others (like me Wink ) IMFD. (If someone managed to do a TEI with transX I pay one beer Wink )
Obviously, that time is past !

As far as I know, yet we still need something to compute the delta V we have to further enter in the DSKY, if we want to make our lunar trip.
I may be wrong but none of the AGC programs (the real as the virtual one) is made for such a task:
I never used the P23 in simulation due to difficulty to run a virtual AGC scenario into TLC but I read a lot of it and it seems to me that its purpose is only to update the CMC with the best estimated position (delta R) and velocity (delta V). for example, it is not able to compute a midcourse correction .
Even the P37 program is not a real navigation computing program: just a back up in case of a total loss of air to ground communications. Once again I may be wrong and would be very pleased if someone could correct me but anyway, it is clearly written about P37 that it cannot work while inside the Lunar sphere of influence. So we may make a earth orbit entry or a direct return abort with it but we cannot hope to use it to perform the TEI.

Stop me if I'm wrong but all the computations were made by ground and then voiced to the crew and further manually entered or directly uplinked to the CMC .
So if we want to simulate the navigation in order to perform an entire mission from liftoff to splashdown, we need "something" to help, otherwise we will just be able to play with one scenario after an other. I don't want to name this "something" an "MFD"; I know that people in this forum hate this word and dreams about a fully "MFDless" NASSP because in real life, Apollo astronauts didn't have any MFD onboard.
Of course they havn't!
They just have several tens of ground controllers and ingineers instead Exclamation
And as accurate your preprogrammed TLI burn will be, you mandatory need to be able to do some possible MCC. And I'm not talking about the TEI that obviously requires a strong "something" to be accurately computed, and cannot be preprogrammed due to uncertainty about actual lunar orbit.

Has someone any Idea?
Lazy D is working on this issue but I don't know how far he is.

For me the navigation question could be summarized as following:
For almost each required burn, we must use P30/P40.
P30 requires 4 critical values to be entered in: TIG, delta Vx, Vy, and Vz, where x, y and z are expressed in reference to the Local vertical.
What is local vertical while travelling in TLC?
As far as I know, this reference is just like the same as in earth orbit: the Earth (or moon) Centered Inertial (ECI) system of reference. Could someone confirm that?
Let's assume this is right
TIG could easily be computed with a standard MFD like trans X or IMFD, or simply be the historical one. In many case, that works too, at least as far as MCC's are concerned.
More complicated are the delta V values.
Let's take IMFD, for example. Any program of it gives you a total delta V or at least a burn time that can be easily converted in delta V.
But how to find the three components of the delta V vector along the 3 earth centered axis?
Moreover, even if you manage to understand the additionnal informations displayed on IMFD ( Ejected Angle, Plane change component, Rinc and so on) all those digits are computed with the velocity vector as reference. And remember than P30 requires delta V's in ECI.
Yesterday, I spent most of the day trying to find an easy solution to this problem. Unfortunately I have to recognize that I wasted my time.

desesperately, I sended a mail to IMFD's author Jarmonik and asked him if he would cooperate and updating his IMFD for NASSP. I explained briefly to him what I suppose we need for.
I'm waiting for a answer, but I doubt that he would build a dedicated MFD just for us.

Any solution?

Somebody not afraid with space navigation math?

Cheers.
Back to top
View user's profile Send private message Send e-mail
dseagrav



Joined: 03 Dec 2005
Posts: 216

PostPosted: Mon Mar 06, 2006 10:27 pm    Post subject: Reply with quote

I'm going to change this message. I have a better way to do this. You might like it. I've pitched this same idea others before, who will recognise me (and this idea) once I say it, so I will out myself now rather than wait for the truth to be discovered and cause problems later.

I was hoping this wouldn't come up until I had a chance to contribute enough good things to hopefully offset it; You can hate me if you like, and ask me to stop contributing if you wish. Thinking about it while writing this, I really should have said all this stuff up front and asked permission to contribute rather than hope I could hide it.

I am the Suzuran who killed P64 and JD's AFPP. The one who bashed on the GPL and admitted using C++ "like an assembler" and all that embarassing stuff. I killed the AFPP by getting in over my head. Basically, I thought the AGC did all of the work and made a bunch of big claims that I couldn't keep by myself. I ended up wasting almost a year working on just a Saturn/LVDC/LVDA simulation, and when I couldn't find the software (and didn't understand the math) I ran into a wall, stalled and tried to slug my way though a CSM without any proper planning, lied about how far behind I was, and eventually the project died without releasing anything. I still feel rotten for wasting their time. >_< I paniced. Most of the reason I opposed the GPL (and hid the source code from P64 and JD) was because they'd figure out just how far behind I was, and how badly incapable I was of accomplishing our goals by myself.

Guys, if you're reading this, I'm really, really, really, really, very eternally sorry I wasted your time and lied to you. I don't think I can ever possibly apologise enough.

I did come up with a neat model of a Mission Control "Subsystem" that I still think will fill the bill nicely without requiring too much heavy lifting. From the point of view of the "player", the spacecraft is your primary focus and everything else is subsystems. It can be construed from this point of view that Mission Control is just another subsystem of the ship, albeit very remotely connected. I planned to add a few click-spots on the panel for responding to the ground controllers, make up a semi-dynamic "plot" of a mission, and have Ground "talk" to you via the debug line at the bottom of the screen. Ground's lines would come from the air-to-ground loop recording transcriptions and some adding of my own. In the background it would compute burn times and trajectories as part of the vessel DLL, then "say" the results via text and expect the "crew" to re-iterate the results to the computer. Nothing overtly automatic, but sufficiently automatic for one person to accomplish a mission. I never had any actual code for this beyond a mock-up of the Ground state engine and code for printing messages on the screen.

I think this would kick much ass if it could be pulled off.
Back to top
View user's profile Send private message
Swatch



Joined: 15 Feb 2006
Posts: 262
Location: Cincinnati, Ohio

PostPosted: Mon Mar 06, 2006 10:53 pm    Post subject: Reply with quote

To be honest....this sounds very interesting, but time consuming. Perhaps in the future this would be possible (like when we'll also be able to have multiple crew members in orbiter Laughing ). In the meantime, if someone were looking to impliment this...I'd say the best solution would be to write an MCC MFD (oh noes!) It's been mentioned spuradically throughout the forum, but not much has come of it. Ideally, someday, we'll be able to simulate MCC itself (imagine the panels involved there Shocked ), but I know somebody suggested having a MFD that "communicated" with you as an astronaut, similar to how CapCom did. Sounds reasonable and at the same time not extremely hard.
Back to top
View user's profile Send private message AIM Address
LazyD



Joined: 10 May 2005
Posts: 406

PostPosted: Tue Mar 07, 2006 12:52 am    Post subject: Reply with quote

Hi Christophe and dseagrav,

I don't know much about the vAGC, but have been watching the advances you guys are making with interest.

I have also been thinking about how to deal with simulating the role of MOCR, and several possibilities have been discussed. The simplest is to have an MFD that can do the orbital calculations and output delta V and burn times that could then be entered into the AGC. Most of these calculations are quite easy, the TLI and TEI are more complicated. I am already working on a general-purpose MFD that will calculate and perform these burns, or could output the numbers to be entered into the AGC.

What I would rather do is write a standalone program that would compute trajectories outside of Orbiter, and could generate burn parameters that could be acted on by any autopilot MFD or the AGC. Since many of the calculations are iterative and time-consuming, it wouldn't compromise the simulation that way. And communication between such a tool and the AGC could be as simple as reading a file. The sticky part of this is trying to duplicate the ephemeris data inside Orbiter outside Orbiter.

Anyway, my main interest is orbital mechanics and powered flight guidance, and I would enjoy working on this whatever form the tool takes. The number-crunching will be the same anyway, whether it's an MFD or a standalone program, and I'm glad to help with this. I'm not a very good coder, though, and I'm kinda lazy.

I'm glad you brought this up, dseagrav, because I think it will be the next barrier we run into when the vAGC can do everything it really did.

D.
Back to top
View user's profile Send private message Send e-mail
irnenginer



Joined: 29 Jan 2006
Posts: 64

PostPosted: Tue Mar 07, 2006 2:07 am    Post subject: Reply with quote

I have been considering this particular problem of late and have some things to throw out there.

The true AGC was specifically built for out side help in mission dynamics, specifically when it came to burn navigation. The ability for it to navigate with uploaded data is very cleaver and actually makes IMHO an easier math problem to solve in order to get to the moon and back. First a little explanation.

P31 was used far more then P30 for most burns, like TEI, LOI, and Midcourse. Instead of using a "Burn in this direction for a certain delta V" it used a "Burn to get to this point at this time" approach(like P37). This type, called Lambert guidance, made for a more flexible mission. Rather then all your burns being time critical and rigid, they could be more open-ended, at least to a degree. It also made computations on the ground easier because you did not need exact computations of spacecraft performance. In addition some parameters did not need to be computed on the fly but could be computed beforehand. Colossus 249 has a piece of memory set aside for the mission return to earth parameters.

I say that it was more open ended because since you knew where the moon was going to be you could set up have a good idea of those "Aim points" long before you got off the ground, only needing to tweak them for the reality of a mission. That is why you here about "PADS" in the comms of the missions. Those are the predefined "where we want to be when". Now there was updates to those as things became more defined. The RTCC (Real Time Computer Center) could compute the trajectory of the spacecraft throughout the mission.

So what we need is a VRTCC. An orbital predictor that could take downlink data from the VAGC (which it can do). Compute burn data based of that point for the upcoming mission events (Like LOI and LEI) and uplink those back up to VAGC (which it also can) All we really need is something to spit out a state vector and time as the aim point that we can "uplink" to VAGC.

I think this approach would be good on a number of levels. I think the math is made easier, since we don't have to compute burn times and directions with extreme accuracy (you would have to know ALOT about the orientation of the spacecraft and the IMU for that to work). I also believe it has the beauty of simplicity. It would not even really need a fancy GUI, just a bunch of number crunching.

This would, unless someone picks it up leave the C++VAGC hanging, but I believe that the hurdles are manageable if we wanted to get that work in the same setup. There are also some challenges with the VAGC state vectors that need to be addressed (which will need to be anyway)

Your thoughts are much appreciated. I suggest you take a look at section 5.3 of GSOP for more on what I am talking about from a VAGC perspective.
Back to top
View user's profile Send private message
Christophe



Joined: 09 Feb 2005
Posts: 280
Location: France

PostPosted: Tue Mar 07, 2006 9:54 am    Post subject: Reply with quote

Hi !
Glad to see that irnenginer, dseagrav, Swatch, LazyD... all the big brains are in action Wink
dseagrav wrote:
Guys, if you're reading this, I'm really, really, really, really, very eternally sorry I wasted your time and lied to you

If there is only one guy that doesn't waste our time (at least mine) it's you Very Happy
In only a few days you wired a bunch of features we were wainting for so long: working RCS under DAP control, RHC, FDAI rate needles... the list is so long.
Never mind about AFPP, this is past. Just stay with us.
Lazy D wrote:
I am already working on a general-purpose MFD that will calculate and perform these burns, or could output the numbers to be entered into the AGC.

irnenginer wrote:
So what we need is a VRTCC. An orbital predictor that could take downlink data from the VAGC (which it can do). Compute burn data based of that point for the upcoming mission events (Like LOI and LEI) and uplink those back up to VAGC (which it also can) All we really need is something to spit out a state vector and time as the aim point that we can "uplink" to VAGC.

dseagrav wrote:
Mission Control is just another subsystem of the ship


That sounds like everybody is thinking roughly the same way:
A calculator that computes trajectories in the way irneginer pointed out and we can called virtual RTCC or virtual Mission Control and displays digits to be entered or uplinked into the AGC.
irnenginer wrote:
P31 was used far more then P30 for most burns, like TEI, LOI, and Midcourse

Sorry but I have some doubt about that... According to most of documentations, P30 was usually used for almost all burns, especially MCC's LOI and TEI. I don't say it's impossible to use P31 to do that, after all I never use it in such a purpose and it's worth the price to try, but I'm just saying that I never read things like that.
Back to top
View user's profile Send private message Send e-mail
LazyD



Joined: 10 May 2005
Posts: 406

PostPosted: Tue Mar 07, 2006 3:17 pm    Post subject: Reply with quote

irnenginer,

It would be equally easy to output a destination aim point and arrival time as a burn time and delta V vector - the two imply each other. In fact I am going to use Lambert steering for my MFD.

My calculation code is easily portable, so we can do this in any form that works for the vAGC. I will need some help with uplink and downlink, and making sure our coordinate systems and units correspond, but I think I can handle the number crunching part.

My TLI code isn't finished yet, but it's getting close. When the next version of Orbiter comes out, the internal ephemeris routines will be available and prediction accuracy will be improved, but it's not too bad the way it is. It starts in a parking orbit, calculates the length of time it will take for the target (moon) to intersect the parking orbit plane, then calculates a transfer trajectory that gets there at the same time. The nit-picky part is trying to into the proper moon orbit plane to pass over the landing site at landing time.

D.
Back to top
View user's profile Send private message Send e-mail
Christophe



Joined: 09 Feb 2005
Posts: 280
Location: France

PostPosted: Tue Mar 07, 2006 6:03 pm    Post subject: Reply with quote

Quote:
It starts in a parking orbit, calculates the length of time it will take for the target (moon) to intersect the parking orbit plane, then calculates a transfer trajectory that gets there at the same time. The nit-picky part is trying to into the proper moon orbit plane to pass over the landing site at landing time.


Are you sure this way of doing can match a real Apollo timeline?
Just a question.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Meadville Space Center Forum Index -> Programming All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
Page 11 of 18

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group