20,741
edits
Talk:Aircraft checklists: Difference between revisions
Jump to navigation
Jump to search
m
→In-air startups & supporting Startup Situations: should probably be moved to a separate article ...
m (→In-air startups & supporting Startup Situations: should probably be moved to a separate article ...) |
|||
| Line 124: | Line 124: | ||
Richard Senior has created an [[Aircraft Checklists#Automated checklist execution|automated checklist script]] to implement autostart on the Lockheed 1049h: | Richard Senior has created an [[Aircraft Checklists#Automated checklist execution|automated checklist script]] to implement autostart on the Lockheed 1049h: | ||
{{cquote|It is trivial to add other checklist sequences. For example, on the 1049h, although I initially created an “autostart” sequence, I now have "ground-start” and “in-air-start” sequences. The ground start fires up the aircraft ready to take off and the in-air start runs the checklists necessary to get it into a flying state (gear up, flaps up, etc.).|Richard Senior}} | {{cquote|It is trivial to add other checklist sequences. For example, on the 1049h, although I initially created an “autostart” sequence, I now have "ground-start” and “in-air-start” sequences. The ground start fires up the aircraft ready to take off and the in-air start runs the checklists necessary to get it into a flying state (gear up, flaps up, etc.).|Richard Senior}} | ||
{{FGCquote | |||
|1= My current guess is very crude: Currently the entire -set.xml is overlaid on the property tree. I would extend this with additional overlays based on some ‘phase of flight value’, where the values are - cold-and-dark - pre-takeoff - cruise - approach It’s interesting to note the difference between ‘cold-and-dark’ and ‘pre-takeoff’ is essentially the same as what the existing auto-start functionality does in most aircraft. But this would simply be a set of property values. For anything which requires Nasal, I guess the aircraft scripts would have to check the value of /sim/presets/phase-of-flight and adjust things accordingly. (And there’s presumably lots of complexity there) I need input from aircraft authors on how feasible this is, of course. But the usability pay-off is potentially huge; standardised auto-start, nice in-air starts, easier setup of training configs. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34642417/ | |||
| title = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki> | |||
| author = <nowiki>James Turner</nowiki> | |||
| date = Nov 23rd, 2015 | |||
}} | |||
}} | |||
{{FGCquote | |||
|1= My original idea was to use different *-set files to do positioning and system initialiation based on phase of flight. This did not work. Now I'm using different set files to mark phase of flight and Nasal to correctly position/initialize the state of systems. In general, I found this complicated. For instance, starting in the final glide phase, I definitely want to initialize with APU and hydraulics on (otherwise airfoils don't work). APUs take some 30 seconds to spin up to full RPM, only then can the hydraulics pumps be engaged, however engaged hydraulics pumps prevent the APU from starting - so you have to do the exact sequence of APU on - wait - hydraulics pumps on. There's no way to initialize this in a single frame. There is also no way that JSBSim picks it up 'running' if I just set the properties in the *-set file to what they'd be if the system would be running. While a correctly timed Nasal script is able to flick all the switches to power the hydraulics up, it's going to take 30 seconds, which is a long time if you're in air and without control. So, there's a 'cheat' switch which by-passes the APU/hydraulics modeling and just tells to the system that hydraulics power is unconditionally available - I use the cheat switch to power during startup and switch to the regular system after 45 seconds when doing an in-air startup. There's by now a handful of different solutions taking care of other subsystems which come with their own problems when they should be initialized running (or absent - for instance SRBs are needed only for two minutes and not allowed to hang around...) Point being, there's no way this is going to be easy. For more complicated systems modeling, you need a combination of custom-rigged JSBSim and Nasal to initialize a correct in-air start. Initializing with a viable state vector is also not that easy - I had to code Earth's rotation into the startup Nasal to get to the same orbital parameters independent of heading, I suppose airplanes will have to explicitly encode wind. I think it's a task that can be done, but especially for the complex planes (i.e. precisely when this would be most useful because 'just' initializing them in-air doesn't do the trick) this requires a dedicated effort by the developer and changes all the way into the systems modeling itself (plus a handful of dirty tricks). There's little that can be automated (as I said, I had to work around a handful of different challenges), and it can be done right now with different *-set files setting a flag which phase of the flight to describe. | |||
|2= {{cite web | |||
| url = http://sourceforge.net/p/flightgear/mailman/message/34643252/ | |||
| title = <nowiki>Re: [Flightgear-devel] Launcher changes for 3.8</nowiki> | |||
| author = <nowiki>Thorsten Renk</nowiki> | |||
| date = Nov 24th, 2015 | |||
}} | |||
}} | |||
<references/> | <references/> | ||