Know the future through the past

 Virtual AGC Goto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next
Author Message
irnenginer

Joined: 29 Jan 2006
Posts: 64

 Posted: Sat Feb 25, 2006 5:41 am    Post subject: 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
Christophe

Joined: 09 Feb 2005
Posts: 280
Location: France

Posted: Sun Feb 26, 2006 8:28 am    Post subject:

 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...
Tschachim

Joined: 26 Nov 2004
Posts: 1272

Posted: Sun Feb 26, 2006 3:30 pm    Post subject:

 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...

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
Christophe

Joined: 09 Feb 2005
Posts: 280
Location: France

Posted: Sun Feb 26, 2006 3:47 pm    Post subject:

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
 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
Tschachim

Joined: 26 Nov 2004
Posts: 1272

Posted: Mon Feb 27, 2006 2:44 pm    Post subject:

 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...

Cheers
Tschachim
movieman

Joined: 25 Nov 2004
Posts: 1018

 Posted: Mon Feb 27, 2006 2:59 pm    Post subject: 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.
Swatch

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

 Posted: Sat Mar 04, 2006 4:13 pm    Post subject: 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.
Christophe

Joined: 09 Feb 2005
Posts: 280
Location: France

dseagrav

Joined: 03 Dec 2005
Posts: 216

 Posted: Mon Mar 06, 2006 10:27 pm    Post subject: 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.
Swatch

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

 Posted: Mon Mar 06, 2006 10:53 pm    Post subject: 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 ). 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 ), 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.
LazyD

Joined: 10 May 2005
Posts: 406

 Posted: Tue Mar 07, 2006 12:52 am    Post subject: 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.
irnenginer

Joined: 29 Jan 2006
Posts: 64

 Posted: Tue Mar 07, 2006 2:07 am    Post subject: 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.
Christophe

Joined: 09 Feb 2005
Posts: 280
Location: France

Posted: Tue Mar 07, 2006 9:54 am    Post subject:

Hi !
Glad to see that irnenginer, dseagrav, Swatch, LazyD... all the big brains are in action
 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
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.
LazyD

Joined: 10 May 2005
Posts: 406

 Posted: Tue Mar 07, 2006 3:17 pm    Post subject: 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.
Christophe

Joined: 09 Feb 2005
Posts: 280
Location: France

Posted: Tue Mar 07, 2006 6:03 pm    Post subject:

 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.
 Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First
 All times are GMTGoto page Previous  1, 2, 3 ... 10, 11, 12 ... 16, 17, 18  Next Page 11 of 18

 Jump to: Select a forum Meadville Space Center----------------General NewsOrbiterProject MercuryProject GeminiV2Off TopicRob Conley's Blog NASSP Apollo----------------General NewsPlanningProgrammingModellingSounds October Sky----------------General NewsPlanningProgrammingModellingSounds Mars Direct----------------General NewsPlanningProgrammingModellingSounds DeltaBlue----------------General
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