Meadville Space Center
Welcome, Guest. Please login or register.
March 30, 2020, 09:02:56 AM

Login with username, password and session length
Search:     Advanced search
Welcome to the new Meadville Space Center forums!
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 ... 22 Print
Author Topic: Checklist MFD  (Read 98970 times)
lassombra
Moderator
Sr. Member
****
Posts: 410


View Profile Email
« on: December 19, 2007, 03:45:29 AM »

Per discussion in my other thread, I have started this thread.  The question that I've seen crop up a couple times now is one of the Checklist MFD.

What am I talking about:

The idea of a apollo Checklist MFD is that it would allow a user to open the MFD, tell it which checklist to run, and then the MFD would list off things that need to be set (reading the actual switch locations...) and highlight the switch after telling the user which panel to look at.

Simply put, the panel side work for this is done.  Switches have a command to be highlighted.  Switches can return their state.  The MFD needs to be properly programmed to identify what switch where, when.  Some parts might be auto triggered by time relative events (maybe we trigger the battery charge initiate at a certain time.


What the problem is:

This is a major undertaking, and not one any of us want to walk into without our eyes WIDE WIDE WIDE open.

My suggested resolution, pending discussion of course:

I personally am inclined to implement the checklist controller as a separate NON-MFD plugin (these are constantly available).  This plugin can give us simple access. 

In timestep it decides whether it's time to start a checklist, or the next phase of the checklist and starts outputting it to either the PAMFD or a second dedicated Project Apollo Checklist MFD. 

It also gives us an interface through which we can select a non-time relative checklist.

When it decides to tell us a checklist step, it does so by:
  • Telling the MFD the panel, switch, target position, and GET/TIG time, whether it was GET or time to Ignition
  • Highlighting the appropriate switch
  • Telling the MFD to play a sound (if desired).

The question then becomes how to put it into the system.

I personally was thinking of this kind of layout:
A single TEXT file in the core directory specifies what checklists are available (directory name) and, if relevant, what GET it will happen at.  If not relevant it will say -999999 (or some such totally useless number, but not 0, that is useful).  So the format would be <directory Name>
<When to execute>
<Next directory Name>
<When to execute next>

and so on...

In the directory would be a file called checklist.txt

The files would have the following in each line, separated by commas:
  • GET/TIG (For output to the MFD)
  • The Panel number of the exact switch
  • The name of the switch, EXACTLY as it is called internally
  • The name of the switch as we want it to appear
  • The direction we want the switch internally (Up, down, left, right, center, 0, 1, ...  These would correspond to actual selectable positions obviously, but also to what we are able to read.)
  • The text we give the user to describe the switch position
  • A single digit (0 or 1) deciding whether this is a time relevant item (do we wait till this time to trigger it.)

finally a number of files called 7.txt through 17.txt would define the "script" for systems related checklists that only have a mission specific timeline.
The syntax would probably be as follows:
  • GET
  • Optional?(would only be shown if the user had selected to show optional checklists)
  • Name of the folder holding the checklist

Note that this is simply my idea, and other people can feel free to expand it.  I should warn that while most c++ is not beyond me, this might be as file operations are really different in c++ relative to Java which is my original language.  I've never really learned file I/O and may find myself having problems here.
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 #1 on: December 19, 2007, 04:13:08 AM »

I have a lot to say on this subject, but its too late (early? which is 4AM?) to do that right now.  I've been putting a lot of thought into the interface for this one, and as a result have come up with some checklist format conclusions also.  I'll try to compile my ideas when it isn't so early/late in the morning/evening.

As far as File I/O is concearned, unless someone here is very good with C++ I/O, I'd suggest using standard C I/O, which is easier to understand and use.   When used correctly, it will result in fast, reliable file handling.  This is of course dependent upon nobody else having objections to the standard C I/O calls.
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 #2 on: December 19, 2007, 06:25:19 AM »

I have no objections, but I'm really looking forward to reading your ideas.  My ideas up there ^^ were cropped together in about 20 minutes from thinking about the various interfaces that orbiter provides and trying to think of one that would work well for this.
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 #3 on: December 19, 2007, 08:07:16 AM »

I'm realy interresting about a proper checklist MFD for NASSP. That's realy interresting way to follow a checklist. Fine idea  Yes

But, if any of you create a MFD like that, please take your major information for this MFD display, from a input file. By this way, i can translate in french for my usage. This input file can be a sequential event for this purpose.

But MFD is very short box to display any information. Probably, that interresting to create a bigger MFD for that.  Undecided
« Last Edit: December 19, 2007, 08:21:28 AM by Coussini » Logged

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


jasonims
View Profile
« Reply #4 on: December 19, 2007, 12:33:35 PM »

Ok, lets see what I've got....  Keep in mind, some of this may be repeats on what lassombra said, I'm mostly copying this from a text file I'd been working on.

MFD INTERFACE:
Below is a picture of how I would do an MFD.



Let me describe the different things...

Buttons:
CHK- Return to checklist selection menu
INFO- Opens a Dialog Box with more information on Checklist or Step (stored in a comment field of the input file)
AUTO- Toggles Optional turning on auto event checking.... I'm not sure about this one, but maybe we could have some sort of code that recieves a required event from the checklist and then when it sees it's been done, it tells the checklist to continue.
HINT- Toggles the flashing switch display
PgUp/PgDn- Exactly what it says, scrolls the MFD view by large jump
Up Arrow/Down Arrow- scroll by one checklist command
checkmark- proceed/success, selects checklist from menu, or marks step as completed
X - back/failed, menu navigation, or marks step as failed, and if it fails and has a failure option in input file, executes failure option (such as going to an abort checklist, or returning to previous step)

Display:
Green box in center is current step
small red yellow, blue and green boxes are each steps status.
-red: failed
-green: succeeded
-yellow: Caution-current Mission Time/Event Time is later than this step (not really sure about this one)
-blue: not a step, just a comment in the checklist
Time has ###:##:## format if it is in Mission Time and ##:## if it is talking about the Event Timer

To simplify coding greatly, and make it more open to modifications later on, we shouldn't base the checklist on events from inside ProjectApollo, and should instead make the pilot "check-off" each step as they go. (or they can just choose to scroll down and not check it off in the MFD)  The Auto option I have in there was something I figured we could add later on, but we could also just have that be a simple event check code.

INPUT FILES:
Possibly Excel spreadsheat or XML to allow easy indexing.

When a checklist is loaded, the input file is parsed and placed into memory using an array of "Step" structures.  Each structure is a combination of enums, unions, structs that contains a complete description of that step.  Until this checklist gets unloaded, this is where the checklist program gets and stores its information.

Required Information:
Entire Checklist
Checklist Name
Checklist Description
Number of Steps
Each Step
Indentifying number (decimal number defining order of steps, so step 1 is 001.00, 2 is 002.00, etc and if someone wanted to add something in between, 001.50 would be read as between them)
Description (text string that gets displayed)
Status (SUCCESS, FAIL, CAUTION, NONE, etc)
Type FLAG (SWITCH, COMMENT, VERIFY_SWITCH, VERIFY_DISPLAY, DSKY, etc.) This will decide what type of sub-structure exists for storing event information
  • SWITCH: requires flipping a switch
  • COMMENT: just a text line with information on it
  • VERIFY_SWITCH: check a switches state
  • VERIFY_DISPLAY: check a displays value
  • DSKY: DSKY commands
Event Information (specific to the Type of step)
-Some information that might be stored here...  Switchname, switch location, event time, event requirements
Failure Mode (specifies what is to be done in case of failure)
Additional Information (text string(s) that get(s) displayed in a seperate Dialog Box when INFO is pressed




I've run out of time for now....I'll post more later and as I find it.
« Last Edit: December 19, 2007, 12:35:50 PM by Swatch » 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)
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #5 on: December 19, 2007, 01:11:25 PM »

That's interresting.

Actually i use MFD checklist for that and i use it with floating MFD (external MFD) because it's more easy to follow and find a button with this mode. This MFD use a TXT file for that.

Your idea is interresting, but the fonts size for the display will be very short. Huh

By your MFD, i can translate the excell sheet for my purpose and it will be fine for me.

Can you explain more about the info button. You open a dialog box when Orbiter is up Huh



* mfd checklist.JPG (45.74 KB, 514x451 - viewed 3022 times.)
« Last Edit: December 19, 2007, 01:16:32 PM by Coussini » Logged

Have a nice day
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #6 on: December 19, 2007, 01:17:18 PM »

One thing that needs to be added is a means of looking up panel items by name, so you can turn the flashing borders on and off. I guess that would go in the panel switch listener class, and then you'd need a way of ensuring that the vessel you were talking to was the right class.

Alternatively maybe it could just be bolted onto the connector vessel class that I added recently and use a special MFD connector to send commands and queries. That might be a better approach.
« Last Edit: December 19, 2007, 01:18:55 PM by movieman » Logged
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #7 on: December 19, 2007, 01:20:57 PM »

In fact, I'll add the connector stuff today or tomorrow, so you can do something like activate flashing for a named item, query the value of a named item, and disable flashing afterwards.
Logged
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #8 on: December 19, 2007, 06:45:16 PM »

So, you can do a flashing mask in transparency like my following exemple and when the user press the
checkmark in MFD, the flashing mask disapear (finish flashing). A big section of button is probably more simple than a flashing mask for each button. That's only a idea.

For the next step:
EDS AUTO - OFF                2

You can do the next:


* panel.gif (173.54 KB, 400x451 - viewed 2090 times.)
« Last Edit: December 19, 2007, 06:51:34 PM by Coussini » Logged

Have a nice day
movieman
Moderator
Hero Member
****
Posts: 1710



View Profile
« Reply #9 on: December 19, 2007, 06:48:49 PM »

Right now, you just get a flashing yellow box. But there's no fundamental reason why we couldn't flash an entire SwitchRow as well.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #10 on: December 19, 2007, 07:58:38 PM »

Actually i use MFD checklist for that and i use it with floating MFD (external MFD) because it's more easy to follow and find a button with this mode. This MFD use a TXT file for that.

An XML file is pretty much just a TXT file that is easy to parse through.  There are lots of C++/C hooks for XML parsing that we can use.

Quote
Can you explain more about the info button. You open a dialog box when Orbiter is up Huh

Orbiter actually has stuff in it to handle dialog boxes... and it would just have optional information that the developer would choose to add.
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)
Coussini
Project Team Member
Hero Member
****
Posts: 699


View Profile
« Reply #11 on: December 19, 2007, 09:38:32 PM »

Wow Swatch... that's really interresting idea. The innovation of usage of Orbiter by using this feature.

FINE  Yes
Logged

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


View Profile Email
« Reply #12 on: December 20, 2007, 04:52:49 AM »

I think the actual systems documentation is more of a want when we're talking about having a standard checklist anyways.  While the astronauts I'm sure knew every bulb on their spacecraft just as I know every switch and bulb on the piper warrior I fly, that doesn't mean that they were thinking in terms of systems.  They did what the guys on the ground told them to.  Strictly speaking, the guys on the ground had more time to think about it since there were more of them.  Having a checklist that provides an accurate flight profile is I think more important then than being able to understand every single system.

That said, I think that it is still important, and if we get some people who have the time and understanding to do so, it'd be great if they could document it.

I fully agree with you. Anyway that's what I use to say since the beginning.
Having a MFD for "online" nominal flight plan sounds very good.
On the other hand, having each step, each switch handling, each detail procedure listing in an MFD seems to me to be a non sense.

I'll take you an example:
Some procedures have to be done several times during a flight. Let's say the P30/P40 for SPS burn for example.
Having an MFD that recall you that an SPS burn has to be performed at GET XX:XX:XX could confuse the user since the exact time of the maneuvers is not fix but depends on your current orbit and the delta between the real flight plan and your own mission is hardly predictable.
Even in the reality, timeline differed from the expected flight plan and the actual one. If you're not convinced by that, have a look at the Apollo presskit and at the mission report. The differences are obvious.
So if you have a checklist that tell you to switch the TVC at a specific GET instead of a specific time before the ignition, the user will switch it may be too early and will run out of electrical power far before the end of the mission.

And what about the abort procedures or simply the alternate flight plan?
For the orbiter community the Apollo 7 mission is quite annoying since there is no moon landing and even no docking.
So, the possibility to play with different alternate missions could considerabily improve the interest of that flight.
for examlple it's very funny to try some launch abort mode II. Performing a emergency return (like the Gemini 8 one) could be very interesting too.

So I think that the most important is a doc to help people understanding what they have to do and how systems work.
The wiki is good for that; I looked at the EPS and ECS system and doc seems to be largely enough.
The difficulty is to tell people they have to "work" (a politically bad word!) to familiarize with that.
Logged
Swatch
Moderator
Hero Member
****
Posts: 1003


jasonims
View Profile
« Reply #13 on: December 20, 2007, 07:41:09 PM »

Well, I've put some thought into it, and as of right now, I'm advocating Excel spreadsheets.  XML would be nice, but there's a distinct disadvantage... We'd essentially have two copies of every checklist.  One for the in-Orbiter checklists, the other for outside of orbiter.   If nobody has a problem with this, then that's great... but then we might have problems keeping both up to date with each other.

I propose using excel spreadsheets because as shown by jc, they can produce some nice checklists, as well as having some very easy to use APIs for reading their information using C/C++.

We can make one set of files that will have all the information necessary in them.  Any additional information in the file that is only used by the Checklist code can be hiden, so that when people open up the files outside of orbiter, all they'll see are the necessary columns of information.  This will also make portability and editing a breeze, as there is support for excel format in Linux, Windows, Mac, etc.
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: 1710



View Profile
« Reply #14 on: December 20, 2007, 07:42:17 PM »

So anyway, I'll soon check in a very basic Checklist MFD for others to work on. This is simply a cut-and-paste of the Project Apollo MFD, renamed, with an extra button 'FLSH' which turns flash on and off for the Mission Timer Start switch.

The idea is that someone else can create a proper checklist MFD using similar code to the FLSH button to control the state of the appropriate switches. I don't understand enough about how it works to remove the code we don't actually need.

Note that this requires changes to a bunch of files, so ensure you rebuild everything afterwards. There's now an MFDConnector class which can communicate between the MFD and the panel in a Project Apollo vessel, so that can easily be expanded to do other panel stuff if there's anything we need beyond getting the state and turning flash on and off. I guess a SetState() call may be handy, for example, so the MFD could set the state of a switch itself.

It all seems to work, I just need to install VC++ 2008 so I can fix up the project files for it Happy.
« Last Edit: December 20, 2007, 07:47:41 PM by movieman » Logged
Pages: [1] 2 3 ... 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!