Meadville Space Center
Welcome, Guest. Please login or register.
June 19, 2013, 12:40:25 PM

Login with username, password and session length
Search:     Advanced search
Project Apollo Beta 7.0 released!
http://nassp.sf.net/wiki/Installation
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
| | |-+  Programming (Moderators: movieman, dseagrav, Swatch, lassombra)
| | | |-+  Checklist MFD
« previous next »
Pages: 1 2 [3] 4 5 ... 22 Print
Author Topic: Checklist MFD  (Read 42857 times)
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #30 on: December 25, 2007, 01:28:07 PM »

Hi SWATCH, what is the status of the Checklist MFD developement. I can see your work because i recompile my NASSP DSK data.

1-What is the dependency of this MFD (all input of this MFD to permit a good usage). Should i have a special input for that (like an excell or another file)

2-I saw the flash button... is it working.

3-I know that it's not in the scope for the Quickstart mode. Is it for the standard mode ?

4-Finally, i just want to know if this MFD follow sequentially an input checklist data. By this way, i presume the flash button work according to this input.

I actualy wait to built my documentation because i just want to know if you plan to create a special thing to flash any button (according to a sequential checklist input data). By this way, i can explain in my documentation, that is very easy for any user to find a button because you plan to had a special feature for that.

Do you understand my situation ?
Logged

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


jasonims
View Profile
« Reply #31 on: December 25, 2007, 02:18:14 PM »

the checklist you see in there should be Moviemans work...not mine.   I haven't done much else with this because I think it still needs to be hammered out a bit more from the planning point of view.    I'm reluctant to take a major part in coding this though since I am about to start the hardest quarter of my college career (last quarter before senior year) and it may not leave me much time for this sort of thing.  I'd especially hold off on documenting any of this until it is nearing completion which may be a few months from now.

If I start working on this though, the initial work will be a completely non-automated checklist in order to get the basic format down.  It will be completely up to the user to control the progression of the checklist.  Automation will be something that is added later on, perhaps not even for ProjectApollo7.
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)
movieman
Moderator
Hero Member
****
Posts: 1709



View Profile
« Reply #32 on: December 25, 2007, 02:45:38 PM »

Well, there isn't a checklist in there at the moment, just a demo of how to talk to the vessels to control the panel switches.
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #33 on: December 25, 2007, 03:17:06 PM »

Well, there isn't a checklist in there at the moment, just a demo of how to talk to the vessels to control the panel switches.
Thanks Swatch. Sorry  Duh!

Movieman,

This is only a demo ?

So, if i understand you don't plan to create an automatic checklist (wich button push.... Etc).

Is it correct what i said ?

Thanks
Logged

Have a nice day
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #34 on: December 28, 2007, 06:56:14 AM »

I am willing to take on the coding of this project, but we are far from having a finite plan.

Also, I'll need some help with the file input stuff (especially if we go to excel as I don't know those libraries at ALL).

Swatch, I like your visual "representation" of what this MFD could do.

I personally would like to make this a separate plugin from the MFD itself.  I've been thinking a bit about how we can make this more effective, avoiding excessive plugin use, and I think the answer is to have both MFD's in one module (I've been doing some testing and I think this can be done).

I'll begin working on some proof of concept stuff to make sure we can do what I think we're doing.  In the meantime, I'd like it if someone on here could come up with a finalized format for the Excel sheet.  I'd like to have, AT THE VERY LEAST the following information available for each checklist:

  • Internal switch name
  • GET/TIG of action
  • Position of switch
  • Comments

It doesn't really matter what order so long as it gets standardized by the time we're ready for it.

Any additional information is fine, but I don't know what else will be useful...

MAYBE:
  • Redirect to info, in case of failed step
  • Optional flag
  • Essential flag(causes this to appear instead of other items once it is due)
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
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #35 on: December 28, 2007, 07:39:25 AM »

For me that's very nice. Follow a checklist require to know the position of switch. Using a MFD is the friendly way to follow a checklist without to many paper. This is very usefull because you can update your checklist. When you print a lot of paper, that's to late when you want to update it. You must re-print it... many time. That's not logical. We have an electronic way to do that, that's the future of paper economy Two Cents

That's the chalenge. So, with you idea, that probably resolve this problem.

Thanks
Logged

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


jasonims
View Profile
« Reply #36 on: December 28, 2007, 10:38:59 AM »

Hmmm I have a lot to work with here...

First off, I started doing some tinkering with this myself with the purpose of it only being tinkering but so far I've moved along further than I originally planned to.  lassombra, if you want to wait for a week or so, I can get what I have to a good stopping place and then send you what I've done.  This way you can have all the component pieces that you'll need in place in case you want to build from mine or start from scratch.


I am willing to take on the coding of this project, but we are far from having a finite plan.


I would agree we aren't quite at a finite plan, but I do think we have enough information to implement a rudimentary checklist. 


Quote
Also, I'll need some help with the file input stuff (especially if we go to excel as I don't know those libraries at ALL).

I'm working on streamlining this through the use of a Checklist class... more on that once I finish my tinkering.

Quote
Swatch, I like your visual "representation" of what this MFD could do.

I've expanded this so far, and what I do have is close to my goal visuals.
There are 3 MFD pages so far:
  • Navigation Page:  This will read a config file that contains a list of all the checklists and the paths to the files
  • Checklist Page:  This is the meat of the subject, and will contain the steps.
  • Additional Info Page:  This was originally going to be a dialog box, but it occured to me that this would be annoying to a point, so I just added it as a new page. More on this later...



Quote
I personally would like to make this a separate plugin from the MFD itself.  I've been thinking a bit about how we can make this more effective, avoiding excessive plugin use, and I think the answer is to have both MFD's in one module (I've been doing some testing and I think this can be done).

I'm still not sure I completely understand this approach, but so far I've found that working within the MFD itself is the easiest way to implement this.

Quote
I'll begin working on some proof of concept stuff to make sure we can do what I think we're doing.  In the meantime, I'd like it if someone on here could come up with a finalized format for the Excel sheet.  I'd like to have, AT THE VERY LEAST the following information available for each checklist:

It doesn't really matter what order so long as it gets standardized by the time we're ready for it.

Any additional information is fine, but I don't know what else will be useful...

I don't think I posted it here, but I've been putting a lot of thought into the hierarchy of the individual steps, so when I get a chance I'll post all that I thought we might need.




All that being said, I would like to continue with my tinkering as a sort of demo, and if your (lassombra) interested, I can send you the files necessary so you can see what I have so far.
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)
movieman
Moderator
Hero Member
****
Posts: 1709



View Profile
« Reply #37 on: December 28, 2007, 12:07:42 PM »

  • GET/TIG of action

I'm not sure whether that would work, because you won't always want to do things at a specific time in the mission; unless it's a time relative to a specific event (e.g. preparing for an engine burn) you probably just want to let them set the switches at whatever rate they choose.
Logged
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #38 on: December 28, 2007, 12:32:38 PM »

Yes, especially if we want to have automatically executed checklists (Quickstart Mode), checklist actions need to be triggered by events like stage separations, changes of internal states etc. The events itself would be hardcoded probably, but should be able to enhance easily (kinda EventManager infrastructure, which passes events raised in the Saturn/LM/etc. to the plugin etc.).

I personally would like to make this a separate plugin from the MFD itself.  I've been thinking a bit about how we can make this more effective, avoiding excessive plugin use, and I think the answer is to have both MFD's in one module (I've been doing some testing and I think this can be done).

For my part I'd prefer a plugin, the ProjectApolloConfigurator at best and the MFD would be just as a GUI/terminal, that way we can assure that the checklist handling is always there and can't be messed up (i.e. not loaded etc.) by the user.

About the format: I'm thinking about if it would be better to use the wiki instead. We could discard the current checklists with all the screenshots of the original checklists/AOH, use templates for a formal structure, write a XML export ignoring all additional explanations, images etc. and reading the exported XMLs in the plugin. But that are vague ideas for now, I didn't do any work towards that yet, just something I wanted to mention...  Two Cents

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #39 on: December 28, 2007, 02:33:12 PM »

Ok, I honestly am not the one to talk about implementing the background files that the mfd reads.

My specialty has always been in interfaces, so that's where I'll focus right now until we have a solid base on which I can write the actual plugin.

I'm going to work on some proof of concept, but I think we can eliminate the problem of the user enabling the MFD and not the Plugin or vice versa completely.  Apparently, Orbiter doesn't care how MANY plugins you initialize from the same module, just so long as all "plugin" modules are actually IN the plugin directory and not the main modules directory or the startup directory.
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
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #40 on: December 28, 2007, 04:18:24 PM »

Apparently, Orbiter doesn't care how MANY plugins you initialize from the same module, just so long as all "plugin" modules are actually IN the plugin directory and not the main modules directory or the startup directory.

Yes, but as far as I know the user needs to activate plugins in the plugin directory, but plugins in the startup directory are loaded always automatically.

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #41 on: December 29, 2007, 07:31:13 PM »

Yes Tschachim, that is correct, however Orbiter spits out a hairball if you try to initialize an MFD mode from a startup plugin.  At least it does for me.
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
Tschachim
Project Apollo - NASSP
Administrator
Hero Member
*****
Posts: 3687


nassp.sf.net


View Profile WWW
« Reply #42 on: December 29, 2007, 08:04:34 PM »

Yes Tschachim, that is correct, however Orbiter spits out a hairball if you try to initialize an MFD mode from a startup plugin. 

Yes, among others because of this I suggested to split the functionality in the actual handling/execution part, which would be done in the startup plugin or the vessel itself, and the display/control part, which would be done in the MFD.  Happy

Cheers
Tschachim
Logged

lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #43 on: December 29, 2007, 08:49:10 PM »

What I think we should do is implement a class in Saturn to handle the checklist operations and then have it default to auto unless it detects a specific "plugin" which will be registered but just be a dummy plugin inside orbiter for detection of the activity of the MFD's.

I'll go ahead and start coding some proof of concept stuff for that while I wait for swatch to finish proof of concept of the interface to the files.
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
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« Reply #44 on: December 30, 2007, 06:30:19 AM »

The more I work with designing the class that should go inside the panel, The more I find I want to use excel as our interface.

I'm designing a couple of structures that help define the various items/groups and these structures make a lot of sense as rows on a spreadsheet.

the synopsis is:
Code:
struct ChecklistItem
{
// -------------------------------------------------------------
// index defined dynaimcally at runtime.  All available
// checklists have a group id retrieved from the ChecklistGroup
// structure.
// -------------------------------------------------------------
int group;
// -------------------------------------------------------------
// defined linearly.  This index always defines the item its
// same number of places from the beginning of the checklist
// group
// -------------------------------------------------------------
int index;
// -------------------------------------------------------------
// Either MET (if no relativeEvent is defined) or time before or
// after the event.
// -------------------------------------------------------------
int time;
// -------------------------------------------------------------
// Event from the "events" enum listing the many managed events
// of this system.
// -------------------------------------------------------------
int relativeEvent;
// -------------------------------------------------------------
// group id to go to in the event of a failure of this check step.
// -------------------------------------------------------------
int failEvent;
// -------------------------------------------------------------
// Text to display describing the checklist.
// -------------------------------------------------------------
char *text;
// -------------------------------------------------------------
// extra text to display when the info button is pressed.
// -------------------------------------------------------------
char *info;
// -------------------------------------------------------------
// define whether this checklist will happen automatically in
// quickstart mode
// -------------------------------------------------------------
bool auto;
// -------------------------------------------------------------
// reference to the panel switch that must be thrown, used to
// spawn reference box
// -------------------------------------------------------------
PanelSwitchItem *item;
// -------------------------------------------------------------
// position the switch must be moved to.  Used for auto detect
// of checklist complete.
// -------------------------------------------------------------
int position;
}
struct ChecklistGroup
{
// -------------------------------------------------------------
// index defined at runtime.  Use this in a ChecklistItem struct
// to start the checklist operation of that group.
// -------------------------------------------------------------
int group;
// -------------------------------------------------------------
// Time at which this group should be executed. (available at
// this time)
// -------------------------------------------------------------
int time;
// -------------------------------------------------------------
// Event relative to which the time triggers.
// -------------------------------------------------------------
int relativeEvent;
// -------------------------------------------------------------
// Group can be manually selected from the MFD.  All checklists
// normally visible to the MFD have this set to true.
// -------------------------------------------------------------
bool manualSelect;
// -------------------------------------------------------------
// Checklist can be automatically selected.  If both this and
// manualSelect are false, the checklist will never be displayed.
// -------------------------------------------------------------
bool autoSelect;
// -------------------------------------------------------------
// Checklist group must be executed and takes priority in auto
// selection of checklist items over the existing item.
// Should this be true, then at the defined time, it will begin
// replacing the present checklist with the checklist group.
// It will internally stack up the old group and return once the
// group is done.
bool essential;
// -------------------------------------------------------------
// Name of the group as should be displayed on the checklist.
// -------------------------------------------------------------
char *Name;
}

Basically, there should be a sheet at the beginning of the spreadsheet called "list" or "groups" or some such logical name that contains rows of:
  • time: This is relative to an event or is MET, either + or - both are valid.  If empty, will be ignored.  Determines relative or MET based on the next item
  • relativeEvent: This should be an event from the list of available events and should match the name precisely.  If it doesn't or is blank, time will be assumed to be MET
  • manualSelect: Whether or not this checklist is available at any time in the mission.
  • autoSelect: Defines whether or not this checklist is automatically selected when the MFD requests just "any" checklist that needs to be done.
  • essential:Has override permission.  This group will actually spawn itself at the proper time over top of any other group listed and will go away when it is done causing whatever other group was running to resume.
  • Name: The name of the group, (IE launch, abort, etc...) also the exact name of the sheet.

The remaining sheets should be named according to name from the first sheet and should have the following items:
  • time: Same as for group, except that this time can be defined as time from the start of the checklist (So, I start the maneuver checklist, and ten minutes into it I want to trigger this item).
  • relativeEvent: This is the same as for the groups  If entered as -2 will define relative to checklist start.
  • failEvent: The name of the checklist group to spawn if the item fails
  • text: The text to display on the MFD.
  • info: The text that appears in the popup info box.
  • auto: Whether this step should happen automatically or not.
  • PanelSwitchItem *item: Could be a number indicating the switch, or the full name of the class.  I'm not sure yet how to implement the switch finding function.
  • position: The position internally that the switch should go to.

What this does is allows us to build a spreadsheet that will do 2 things:
1) It allows external editing of the quickstart mode functions.
2) It allows external editing of the actual checklist functions.

This spreadsheet could actually be mission specific allowing even quickstart missions to follow the full mission checklist pretty completely.
I'm primarily at this point going to work on designing the interface that the MFD will use, including access to the various checklists and how they will work.  I'll post back here when I have more.
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
Pages: 1 2 [3] 4 5 ... 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!