Meadville Space Center
Welcome, Guest. Please login or register.
July 09, 2020, 11:33:46 PM

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
| | |-+  Planning (Moderators: movieman, Swatch, lassombra)
| | | |-+  Project Apollo MFD ideas & concepts
« previous next »
Pages: 1 2 [3] Print
Author Topic: Project Apollo MFD ideas & concepts  (Read 21203 times)
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #30 on: July 26, 2007, 05:09:56 PM »

Hey dseagrav, I think I have a much better idea of what you were saying earlier.  Before I start on it though, I have a suggestion about the internal MCC and I want to know how you feel about it.

Right now you have MCC as its own super-class in mcc.cpp, but within that class all you are doing is the ground track stuff....  How would you feel about making another groundtrack class that inherits the MCC class and then I'll make a capcom class that inherits the MCC class as well, that way we globalize the MCC class a bit and make the addition of seperate functions within the scope of an internal mission control a bit cleaner to program?  The other thing this might allow us to do is to set up a method to selectively turn on and off the individual functions of the MCC from the External MCC, so that it's not an all or nothing type of thing.

If you want to see what it would look like, I went ahead and tested it to see if it would work, so I can post what I have here on the forums for you to look at and see if its good or not.

EDIT:

I attached the .h and .cpp file for you to get a good idea of what I changed.  if you like it I can commit what I have so far since it compiles correctly (there were 1 or 2 other changes made to other files).

* mcc.cpp.txt (9.43 KB - downloaded 324 times.)
* mcc.h.txt (5.12 KB - downloaded 268 times.)
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)
dseagrav
Project Admin
Hero Member
*****
Posts: 1118


View Profile
« Reply #31 on: July 27, 2007, 11:35:13 AM »

Sorry for the lateness of the reply.

That doesn't look bad. Go for it. Having a class for each MCC station would make it easier to standardize information flow between them and make it possible for someone to mix local and remote MCC.
Logged
jc121081
Project Team Member
Full Member
****
Posts: 84


FAO


View Profile Email
« Reply #32 on: February 16, 2009, 04:20:52 PM »

Here is an idea I had that has been stirring through my brain recently...

The GNC button in PAMFD has, in my opinion, the probability to house new potential. What I was thinking is maybe there could be a new set of options (buttons) to select after selecting the GNC button? Confused? Here is what I had in mind, clear and simple...

The GNC function would contain these new options that the user could select:
A "ORB" option
A "TLC" option
A "LOI" option
A "TEI" option
And a "TLC" option

Now I know that this may seem unlikely, but what if hypothetically each of these options, once selected, could ask the user to define option-specific desired trajectory or orbital parameters, each calling upon their own set of formulas to calculate burn velocities, then uplink the burn pad values to the vAGC?

Now again, it may seem like all of this may be way off in left field, so to speak, but the capability is there. If you take a look at our very own AGC++ coding, for example, some formulas are there to calculate from Orbiter's relative vessel position to determine orientation and resultant parameters. (Simple AGC programs 19 and the rendezvous programs for example). What if there were some way to take these types of code and modify them into different, mission phase specific formulas that could be incorporated into PAMFD?

Here is an example of how it would work:

User is flying Apollo 8 vAGC, prior to MCC1. The user would open PAMFD, click the GNC button, and then click the proposed "TLC" button (Trans-Lunar Coast navigation mode). PAMFD would display a blank screen similar to what we would see when we request burn data from IMFD. There would be another set of buttons the user would click to specify the desired trajectory parameters. During the TLC phase, the desired lunar pericinthion conditions are the variables, so the user would set values for the desired mission time of pericinthion, the PeA, Lat, and Lon. Once set, PAMFD would perform calculations based on Orbiter's relative vessel state vectors and the moon, and display the calculated variables into LVLH velocities that either A: Can be stored into the vAGC via P30, or B: be uplinked to the AGC in a similar fashion that our state vectors are, and performed from there.

Again, this is only an idea...
Logged



Current Work:
Overhaul of Ap8 vAGC FP, Wiki FP's

Future Work:
Ap14 Q FP, Ap15 Q FP, Ap16 Q FP, Ap17 Q FP
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #33 on: February 17, 2009, 05:47:27 AM »

PAMFD would display a blank screen similar to what we would see when we request burn data from IMFD. There would be another set of buttons the user would click to specify the desired trajectory parameters...

Well, given the complexity of this stuff the plan is to actually use IMFD for this as we're using it for TLI already. Currently PAMFD can request burn data for all the burns you listed including MCC's and display them in proper coordinates and units for P30. Next step would be automatic uplink of the burn data similar to the state vector uplink IMHO...

Cheers
Tschachim
Logged

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



View Profile
« Reply #34 on: February 17, 2009, 12:16:03 PM »

I can work on the automatic uplink of the burn data. 
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #35 on: February 17, 2009, 12:50:33 PM »

Great!  Happy

Please wait until I finished the source code move (almost ready), then we should discuss that in a new thread.

Cheers
Tschachim
Logged

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



View Profile
« Reply #36 on: February 17, 2009, 01:04:40 PM »

ok, roger  Very Happy
Logged
Pages: 1 2 [3] 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!