Meadville Space Center
Welcome, Guest. Please login or register.
June 07, 2020, 05:04:33 AM

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)
| | | |-+  Checklist MFD
« previous next »
Pages: 1 [2] 3 4 ... 22 Print
Author Topic: Checklist MFD  (Read 99451 times)
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #15 on: December 20, 2007, 08:01:20 PM »

Ok, that's checked in. Since I did change a lot of files, let me know if I broke anything in the process!

Note that you no longer need to check vessel class names to ensure it's a Saturn or whatever, as the connector code should automatically figure out whether it's a vessel you can connect to (right now that's the CSM and LEM).
« Last Edit: December 20, 2007, 08:14:26 PM by movieman » Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #16 on: December 20, 2007, 09:31:57 PM »

Ok, I added a SetState() call too and some documentation on what the calls do Happy.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #17 on: December 21, 2007, 02:56:09 AM »

Here's a little bit of psuedo-code along the lines I was thinking....

Code:
#define MAXNUMSTEPS "whatever the max number of steps that exist in the files are"

struct ChkLst
{
      ChkLstStep steps[MAXNUMSTEPS];
};


struct ChkLstStep
{
      double IDNumber;
      string Description;  //length should be length of one-line display on MFD

      enum //Status flags...
      {
            SUCCESS,
            FAIL,
            CAUTION,
            NONE
      };
      int status;

      enum //Step Type flags....
      {
            //Following Step Types are displayed as a checklist step
            SWITCH,                  //Step involves changing a switches state
            COMMENT,               //Step does not involve an action, just information
            DSKY,                     //Step involves interaction with AGC
            CONTROL,                //Step involves controlling SC (thrusters, optics, etc)
            VERIFY_DISPLAY,      //Step involves reading or observing one of the displays
            GO_NOGO,               //Step involves a choice, determining next chklst step
            //Following Step Types result in no checklist display
            GOTO_CHKLST,         //Opens a new checklist, keeping place in current one
            END_CHKLST            //End of checklist
      };
      int type;

      union
      {
            StepInfo_SWITCH typeSWITCH;
            StepInfo_COMMENT typeCOMMENT;
            StepInfo_DSKY typeDSKY;
            StepInfo_CONTROL typeCONTROL;
            StepInfo_VERDISPLY typeVERDISPLY;
            StepInfo_GONOGO typeGONOGO;

            StepInfo_GOTOCHKLST typeGOTOCHKLST;
      };

      enum //failure mode flags...
      {
            // If current step fails...
            RETRY,                   //...retry current step until forced to move on or success
            RESTART_CHKLST,   //...reset checklist
            IGNORE                  //...take no action
      };
      int failmode;

      string AdditionalNotes;  //Long string containing notes to be displayed externally
};

// The structures below are primarily used for automation of checklist at a later time

struct StepInfo_SWITCH
{
      /* Will contain information vital to a switch event... i.e. Switch Name, Target State, etc. */
      int TargetState;
      bool Verify;  //if true, then switch should already be in this position
};
struct StepInfo_COMMENT
{
      /* will contain any items specific to a comment event in the checklist */
};
struct StepInfo_DSKY
{
      /* will contain any items specific to a DSKY event... i.e. Target Program/Noun/Verb, etc */
      enum
      {
            SETPROG,
            SETNOUN,
            SETVERB,
            SETREG,
            KEYRLSE,
            RESET
      };
      int DSKYevnt;

      int Target;
};
struct StepInfo_CONTROL
{
      /* will contain any items specific to a CONTROL event... */
};
struct StepInfo_VERDISPLY
{
};
struct StepInfo_GONOGO
{
      /* will contain any items specific to a GO/NOGO event... i.e. GO-result target step, NOGO-result target step */
};
struct StepInfo_GOTOCHKLST
{
      /* will contain any items specific to a GOTO Checklist event... i.e. Target checklist name/section/step */
};

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)
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #18 on: December 21, 2007, 03:43:26 AM »

I can't keep up.

Way cool.

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

Secondly...  incorporating the eoca into an mfd...

I know this is technically is about the checklist mfd, but we are at a point where we are gearing up for release and there is some real truth to the fact that the eoca as it is is not of much use IN orbiter.

I personally don't even comprehend the math, so I don't think I can pull it off, but maybe someone can?
Logged

My current Project Apollo work:

Quickstart to the Moon initiative (Quickstart_to_the_Moon): Done through earth orbit.  Working on new method of calculating TLI.

Checklist Controller: 
  • MFD Interface 99%(Minor cleanup and future features remain)
  • Panel Interface 99%
  • Excel interface and logic 99%
  • LEM Event code.0%
  • DSKY Interface code. Framework complete, creating "buttons"
  Approximately 80% done. (Checklist Controller
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #19 on: December 21, 2007, 04:18:50 AM »

I can't keep up.

Way cool.

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

I absolutely agree.

Quote
Secondly...  incorporating the eoca into an mfd...

I know this is technically is about the checklist mfd, but we are at a point where we are gearing up for release and there is some real truth to the fact that the eoca as it is is not of much use IN orbiter.

I personally don't even comprehend the math, so I don't think I can pull it off, but maybe someone can?

Once we add integration of excel for checklist, then integration from eoca may be very possible as well.   I'm in the same boat as you though, I don't understand the math.
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)
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #20 on: December 21, 2007, 04:36:41 AM »

Secondly...  incorporating the eoca into an mfd...

Would be so cool... a dream for me Rolling Eyes
By the way, If I knew C++ I would have done an MFD directly. As I already mentionned I'd like EOCA would be part of the virtual MCC.

But guys, no problem for the maths. I'm far from an expert but I learned a lot on space mechanics for 1 year and could help you.
By the way the most difficult for me is less math than the logics on how to get the calculator running. Something like:"One table should compute while the other one is in stby and then the computation should starts only if the computation of a third table has stopped..." and so on and so on...
Sometime I wonder if it woulndn't be quicker to learn C++... Undecided
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #21 on: December 21, 2007, 07:54:46 AM »

Secondly...  incorporating the eoca into an mfd...

Would be so cool... a dream for me Rolling Eyes
By the way, If I knew C++ I would have done an MFD directly. As I already mentionned I'd like EOCA would be part of the virtual MCC.

But guys, no problem for the maths. I'm far from an expert but I learned a lot on space mechanics for 1 year and could help you.
By the way the most difficult for me is less math than the logics on how to get the calculator running. Something like:"One table should compute while the other one is in stby and then the computation should starts only if the computation of a third table has stopped..." and so on and so on...
Sometime I wonder if it woulndn't be quicker to learn C++... Undecided

I presume that this project work with Quick start and standard mode ?
Logged

Have a nice day
Christophe
Project Team Member
Hero Member
****
Posts: 1072


View Profile Email
« Reply #22 on: December 21, 2007, 09:18:48 AM »

I presume that this project work with Quick start and standard mode ?

Allthough EOCA is especially designed for vAGC, it should work for any orbiter vessel.
The only thing is to convert the deltaV's into the orbiter usual ecliptic frame of reference.
in fact, for a standard vessel, so in standard mode, the components of delta V's are useless. but EOCA can give you the total delta V instead, and the proper euler angles for burn orientation. Then any of the orbiter autopilot may perform the burn.
Then, with the burn attitude + the time of ignition + the delta V and/or the burn duration, all given by EOCA, you could do the maneuver even with the delta glider for example.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3700


nassp.sf.net


View Profile WWW
« Reply #23 on: December 21, 2007, 11:03:28 AM »

At first I would like to thank all here for picking up this very important feature, keep it up!  Happy Since I'm finally resumed the work on the last remaining CSM systems, I only would like to make some small comments about the checklists.

The first thing is the Quickstart Mode. Except some "specials" like the throttleable SPS engine, in Quickstart Mode some currently "hardcoded checklists" are executed automatically at certain events by using the SwitchTo-function of the various switch classes. The original plan was to replace that sometime by easily editable config files like the excel checklists discussed here. This is nothing mandatory, but perhaps we can keep that in mind while working on this checklist MFD. To achieve that there needs to be a possiblity to load and somehow execute checklists independant of a MFD so that the Quickstart Mode isn't broken when the user doesn't activate the MFD, for example by using the always loaded ProjectApolloConfigurator or by doing that in the Saturn/LM itself and using common Checklist, ChecklistStep, ChecklistLoader etc. classes or something like this. Also the checklists would need to be able to be started by certain events like for example tower jettison, earth orbit insertion or changes of the internal systems state (Saturn::systemsState). The "ideal" situation would be that the realism levels are just a setting how checklists are handled, automatically in Quickstart Mode, manually with the MFD in Standard/VAGC Mode or "in between" like every switch is highlighted automatically until the user toggles it and then the next switch is highlighted etc.

I don't want to spoil the work already done, but I wonder if it's a good idea to put the checklists in a new MFD instead of adding one or more additional screens to the existing one. Programming wise 2 MFDs are fine for me, but the user needs to activate 2 MFDs and can mix them up. I can already see posts like this in my mind: "I can't find the checklists..." - "You need to use the Project Apollo Checklist MFD" - "But I already tried Project Apollo MFD" - "No, the other MFD..." etc, I hope you can imagine what I mean...

Again just my Two Cents, I'm very happy that you guys are working on this important feature!  Thumbs Up

Cheers
Tschachim
Logged

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


nassp.sf.net


View Profile WWW
« Reply #24 on: December 21, 2007, 11:37:40 AM »

...as there is support for excel format in Linux, Windows, Mac, etc.

Just because I'm curious and because of GPL related legal issues, what library/component/tool do you have in mind to read Excel files in ProjectApollo?

Cheers
Tschachim

Logged

movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #25 on: December 21, 2007, 12:31:35 PM »

I don't want to spoil the work already done, but I wonder if it's a good idea to put the checklists in a new MFD instead of adding one or more additional screens to the existing one.

I was wondering that, and can see arguments for both sides. If it does start out in a separate MFD it shouldn't be too hard to bolt onto the Project Apollo MFD later instead, since most of the code would be the same in either case (e.g. reading checklists, displaying them, processing keys).
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #26 on: December 21, 2007, 01:11:18 PM »

On the subject of licensing:

I've been looking around, and so far I've come up with the following as the best....

BasicExcel http://www.thecodeproject.com/KB/office/BasicExcel.aspx  There is no license within the actual files and CodeProject states the following...
Quote
Can I use code snippets and programs in my own work?

Yes. Some authors may have specific restrictions on using code in commercial apps, such as providing credit in documentation or sending them an email first, but all code can be used for free.


On the subject of structure:

I agree that the main checklist handling code should be seperate from a specific MFD.  But I do feel the interface should be integrated into ProjectApollo MFD.  I'm all for making a Swiss-Army Knife MFD for Apollo.  It's simpler to use and easier to explain.

I see three main components here...
1.  Excel API - used to extract information for the Checklist Handling
2.  Checklist Handling - This handles events and automation, as well as always being accessable.
3.  MFD Interface - This is just for the display of the checklists, and it communicates with the Checklist Handling program for its information.
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)
jc121081
Guest
« Reply #27 on: December 21, 2007, 05:30:07 PM »

Swatch, I'm not against excel sheets, infact I think it's a good idea, but we should come up with some kind of standard for them NOW before jc gets too far into his...

Well, in response to this, I can only say that my ambition for compiling the Ap7 vAGC Flightplan (I wish there was a better name for it now Bangs Head) was in no way meant to be formatted a specific way for MFD use (if that is what you are referring to), and I didn't expect to have to change the format either. I made it to add a sense of organization and direction to flying the mission historically, (or at least somewhat historically for the time being) and as a one-stop reference for procedures in the mission, instead of having to open multiple docs, consult the forum, or sift through poorly legible 1960/70's documentation.

I totally respect what you guys are doing with the Checklist MFD, and I hope it goes well for those whom are developing it. However, in my preference (as was another reason for my designing the FP) I was hoping to make this flightplan in hopes that, once completed, it could be printed and referred to just as the astronauts had their own paper flightplans, procedures, and manuals they carried aboard on each mission. I know this flies in the face of what you are intending the MFD for, but again, this is just my preference to promote realism and is always going to be how I personally fly each mission.

If you all wish, you may use the FP in any format you wish for the MFD, that is fine by me. Just understand that as I continue to develop it that it will be in much the same format that it is now. I don't want to discredit the fantastic work that Christophe did in adding the procedures in the "docs" folder, (and would actually suggest those, as well) which are even more detailed than the "simplistic" versions of the procedures included in the FP, some of which are based from those docs. I hope I didn't come off to brash with all this, I just hope that it clarifies some things. Thanks.  Happy

Regards,
jc121081
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #28 on: December 21, 2007, 06:31:45 PM »

If i understand, this checklist MFD is only for the Virtual AGC  Sorry
Logged

Have a nice day
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #29 on: December 21, 2007, 09:24:02 PM »

jc, you misunderstood I think... or somebody did... In no way do I want to replace or modify what you're doing... I like what you're doing.    Yours did however present a good example of what we could do with excel, and it would be Christophe's checklists that would be modified in my mind, since his are the more historically accurate checklists and yours are flightplans.  So don't worry, you keep doing your thing, we want something someone can print off.
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)
Pages: 1 [2] 3 4 ... 22 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!