Hello again,
I have completed a prototype flight simulator using RTLinux. The prototype
simulator is FAA level B capable. It is set atop a 4-degree hydraulic motion
system, with hydraulically actuated control loading. The simulation contains
FAA level B capable flight software, complete electrical, hydraulic, and
pneumatic software systems simulations. Aircraft dual flight instrumentation
with full functionality. Full simulation of dual PT6A-112 Pratt power plants
with constant speed props, full real world nav aid simulation with a dual
compliment of nav radios, GPS, flight director, and autopilot. And a two
window daylight visual system. The I/O subsystem on the prototype simulator
contains:
168 12 bit D/As
60 12 bit A/Ds
400 Discrete outputs
900 Discrete inputs
I am using the periodic scheduler in RTLinux 1.1 installed in Linux 2.0.63.
The scheduler sets up 3 real-time tasks. Two lower priority tasks that are
scheduled at 50msec, and a third real-time task also scheduled at 50msec,
but run at the highest priority level. The first of the two low priority
tasks services the I/O. The second of these calls the simulator module
executive, which in turn schedules and executes all simulation modules. The
modular exec manages and schedules over 70 simulation modules at different
rates based upon required task granularity. Critical flight and engine
dynamics run at 20hz, other less demanding tasks are scheduled and run at
lower multiples of 10, 5, and 2.5hz. The third real-time task monitors the
other two lower priority periodic tasks to insure that they each complete
execution before their respective 50msec periods expire. If either of the
two simulation tasks "time out" they are suspended and a time out message is
queued to be sent to the debug module.
The debug module is a Linux user mode task; it can be run and exited at
will. When operational it links up with the simulation via a shared commons
memory area. When exited, the simulation queues critical messages for
display upon the start of the next debug session. A second background Linux
user mode task is always present. It handles I/O requests (serial, disk, and
Ethernet) from the real-time side, and sends results back via fifos.
I am running on a P2 350 desktop system. One iteration of the simulation
runs in less than 1msec. One iteration of the I/O service also runs in less
than 1msec. This leaves the system free 95% of the time to process Linux
user mode tasks. I am able to run the simulation and run Linux user mode
processes without noticing any loss of performance! I did a complete
re-conversion (from MACRO11 assembler to ANSI C) and recompile of the whole
simulation package WHILE the simulation was running. The process proceeded
at lightning speed, and the simulation never skipped a beat.
I have yet to "scope" the finished product to check jitter for myself. But
all observed results thus far seem to support the figures published
previously in this newsgroup's e-mail.
The next step involves implementing a Level C device. The additions to do
this are trivial compared to the initial task of doing the prototype. I
expect to have a functional level C machine inside of 5 months. Thanks to
all involved in the design and development of this most excellent product! I
am certain more questions will pop up as this project progresses. Many
thanks for your patience and help with my questions during "round one" :)
Sincerely,
Todd Gearheart
FSI Simulator Systems Division
Field Engineering
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/
