|
|
|
Virtual
AGC and AGS
Frequently-Asked
Questions |
|
|
|
Is this project affiliated somehow with NASA, or are any former
Apollo workers involved?
No.
Why waste so much time on a project that may be of interest to 3
geeks somewhere?
Placing men on the moon is one of the
greatest accomplishments of the United States of America. It is
arguable,
indeed, that it is the
greatest
accomplishment (of any kind) in the
history of the human race. If so, perhaps it makes sense to
preserve the relics of the Apollo project. (Besides, I'm one of
the 3. )
I got the idea while watching the movie
Apollo 13. The instant in the
movie where the AGC is powered up on Earth approach is the instant when
the viewer suddenly feels that survival of the astronauts has changed
from "highly unlikely" to "very probable". It gives me a chill
whenever I see it. Anyhow, on watching this one day, it struck me
that it was a shame nobody knew any longer how to operate the AGC---let
alone write the programs for it. (As it happens, that thought was
a bit premature: only 35 years had passed since the AGC software
was written, thus many of the original software developers were still
reasonably young.
Nevertheless, the principle is correct, since
very few people could use or
program the AGC.)
Anyway, it then occurred to me that it would be cool to bring the AGC
back to life, and to allow anyone so inclined to use it or program it
... assuming, of course, that sufficient publically information was
available to do so. As it quickly turned out, there was enough
information publically available, though
just barely enough. The
project turns out to be an interesting experiment in digital
archaeology.
News flash: I found a
couple more geeks, bringing the total to 5. Here's their
website, where
they're doing almost the same thing as me, inspired (no less) by
From the Earth to the Moon. I
don't know whether to thank Tom Hanks or Ron Howard, or maybe Brian
Grazer or somebody else, for this state of affairs. For the sake
of argument, we'll assume it's Tom Hanks. Thanks, Tom, for
warping our fragile, little minds.
Later news flash: I've
found still more geeks. Let's just assume that the total is
around 100 and do away with these further news flashes!
What's with the "ya" stuff all over the place?
Computer programmers are aware --
though Apollo enthusiasts may not be -- that "ya" is often added to
computer program names to mean "yet another". Thus, yaYUL is "yet another YUL", yaDSKY is "yet another DSKY", and so on.
What's the deal with "verbs" and "nouns"?
The following amusing (if not
necessarily helpful) comment may be found in
the source code of the keyboard and display program (otherwise known as
"pinball"):
THE
FOLLOWING QUOTATION IS PROVIDED THROUGH THE COURTESY OF THE AUTHORS.
"IT
WILL BE PROVED TO THY FACE THAT THOU HAST MEN ABOUT THEE THAT
USUALLY TALK OF A NOUN AND A
VERB, AND SUCH ABOMINABLE WORDS AS NO
CHRISTIAN EAR CAN ENDURE TO HEAR."
HENRY 6, ACT
2, SCENE 4
It turns out, though, that the authors' literary skills didn't quite
match their programming skills, as this quote is really from Henry VI,
Part 2, Act IV, Scene VII. (Thanks to Frank O'Brien of the Apollo
Flight Journal and Apollo Lunar Surface Journal for this
correction.) By the way, if you take it upon yourself to actually
read the play to figure out the context, you may find yourself reading
about "a Nowne and a Verbe" rather than "a noun and a verb".
Ramón Alonso provides a little more insight: Apparently,
nobody had yet arrived at any kind of software requirements for the
AGC's user interface when the desire arose within the Instrumentation
Laboratory to set up a demo guidance-computer unit with which to
impress visitors to the lab. Of course, this demo would have to do something, if it was going to be
at all impressive, and to do something it would need some software. In
short order, some of the coders threw together a demo program,
inventing and using the verb/noun user-interface concept (in the
whimsical fashion seen in much of this code), but without any idea that
the verb/noun concept would somehow survive into the flight
software. As time passed, and more and more people became
familiar with the demo, nobody got around to inventing an improvement
for the user interface, so the coders simply built it into the flight
software without any specific requirements to do so.
However, that does not mean that the verb/noun interface was
universally beloved. Ramón says that many objections were received from
naysayers, such as "it's not scientific", "it's not dignified", or even
"astronauts won't understand it". Even though the coders of the
demo hadn't seriously intended the verb/noun interface to be used in
any permanent way, it became a kind of devilish game to counter these
objections with (perhaps) sophistic arguments as to why the interface
was really a good one. In the end, the coders won. I don't
know whether they were elated or dismayed by this victory.
The astronauts, of course, could
understand the interface, but they did not like it. Most of them
really wanted an interface much more like that they had used in
aircraft: i.e., lots of dials and switches. Dave Scott is
the the only astronaut I'm aware of who had kind words for it (or for
the AGC in general), though we are told that Jim McDivitt wasn't
necessary completely hostile to it.
Why Isn't More Information Provided About Why the Guidance System
User Interface Was Like it Was?
A lot of thought about usability went
into the design of the guidance system, much more so than the story
above about verbs and nouns would indicate. Questions like what
kinds of controls needed to be provided, or even where those controls would be
physically located, were extremely important (Thanks to George
Silver for pointing this out.) Sadly, I don't know anything about
these topics, and that's why I don't cover them here.
Tell Us More Amusing Stories
Well ... maybe just a couple more.
- The story of the 1201 and 1202 alarms on the descent by Armstrong
and Aldrin to the lunar surface during Apollo 11 is well known.
(If you don't know it, the astronauts received repeated alarms from the
AGC of type 1201 and 1202 -- 5 alarms in all, if I'm not
mistaken. On each alarm, the question was raised as to whether to
continue or to abort. Obviously, they continued.) I'm
informed that the representative from the MIT Instrumentation Lab who
was present to be consulted by Mission Control was Russ Larson.
When consulted on the go/no-go question, Larson simply gave a "thumbs
up" signal. When asked years later why he had done this, he said
simply that he was too scared to speak. (Thanks to Allan Klumpp
for this story.)
- And continuing on the topic of the 1201/1202 alarms in Apollo
11: These alarms were caused by the fact that during the landing,
both the landing radar and
the rendezvous radar were turned on. Only the landing radar
actually needed to be active, but it was felt by some that having the
rendezvous radar turned on would be useful in case of a sudden
abort. What wasn't known was that this extra load on the AGC CPU
would cause it to run out of processing cycles. The software
would work all right at first, but eventually the loss of about 15% of
the CPU cycles due to processing the excess radar data would cause some
tasks to be spawned before earlier instances of those tasks had
completed running. Eventually, because of the duplication of
tasks, the software would be unable to allocate the memory needed to
spawn new tasks, and would need to restart. Fortunately, the
cunning design of the software allowed the software to basically
continue executing at the same point where it had been before
restarting, and so it could continue operating normally until it ran
out of memory again. Eldon Hall likes to point out that this is a
success of the AGC rather
than a failure (as some other
people like to say). At any rate, Allan Klumpp coded a workaround
for this problem in time for the Apollo 13 mission, but the
powers-that-be declined to use the new software. Klumpp was upset
enough about this to contact the mission commander, Jim Lovell, and
describe why the new software (Luminary 131) would be so much better
than the old. The next morning, Dick Battin dropped by Klumpp's
office and announced, "Allan Klumpp, your political savoire-faire has descended to a
new low!" That was his way of saying that Luminary 131 would be
used on Apollo 13 after all, because Jim Lovell wanted it.
- The original source code for the AGC assembler program called
"YUL" isn't presently publicly available, though I expect it will be
soon, and I'll link to it when it is. However, here is a scan of pages 2 and 3 of the
listing for YUL. Please examine it closely. I needn't
comment further.
- Not an AGC story, but I like it: I'm told that one of
the perks of writing software at MSC in the Apollo era was
taking the coding sheets to the 'swamp' for the
keypunch operators to build the card decks to be taken to the computer
center. The 'swamp' was a tiered auditorium with many young
women at keypunch machines on the tiers. Of course, the
young engineers
would enter the room at the front at what was the focus of the
tiers, feeling a little like a bull at the rodeo auction.
Apparently, this was a good way to meet bored young women in need of
stimulation. This is a case, obviously, where progress has been
in completely the wrong direction. (Thanks to Paul Schlein for
this story.)
Wouldn't it be better to incorporate Virtual AGC into a flight
simulation
or lunar landing simulation?
Yes. I would strongly encourage
it.
But it's outside of my personal limits, workload-wise. If you
want to work on that, I may be able to connect you to other people who
are also interested in doing so.
If you do want to work on this, I'd
strongly
advise that you use (or adapt and improve) the socket-based
interconnect model I've provided and described on the
developer page (so that yaAGC can be used as
a stand-alone program), rather than trying to cut-and-paste
yaAGC code into the
flight-simulator. Remember that even though Virtual AGC is free
of cost, you are still bound by the licensing provisions of the
General Public License (GPL); in other
words, there are consequences for misuse of the code. If, for
example, you insert
yaAGC code
into a flight simulator, then that flight simulator must also be
open-sourced under the GPL, or else I would have to grant you a special
exception to the license. (For example, I have granted such an
exception for the
Orbiter
program. See below.) On the other hand, if you use
yaAGC as a stand-alone program that
merely communicates with the flight simulator, then there is no such
problem. Remember also that Virtual AGC is a work-in-progress,
and if you insist on customizing
yaAGC
itself, you will have to carefully consider what you intend to do when
I improve it without consulting you, and you have no way to merge the
changes.
Work to integrate Virtual AGC into the
Orbiter
spacecraft simulator has proceeded marvelously.
There is a
Sourceforge project,
complete
with working code and documentation such as installation instructions.
I'm told that integration into
FlightGear
is proceeding well
also, though not yet at the point of having screenshots to show you.
How come the stuff the simulation can do is so trivial?
It takes more than just a computer to
fly an Apollo LM or CM. At the very least, you need simulations
of the spacecraft's IMU, AOT, and of the physical spacecraft (i.e.,
acceleration, torque, fuel usage, etc.). Maybe we'll have those
things, one of these days. The
LM_Simulator module is making
very good progress towards providing an IMU.
It doesn't work! How do I make it work?
Troubleshooting Compiling
- In Linux: Some users have found that the 'configure' step
does not work properly. I have no explanation or fix for this as
of yet, but if you're UNIX-savvy I'd point out to you that the
Makefile.Win32 file contains steps (for MS Windows) for building the
program without using autoconf.
So, you might be able to adapt the steps from Makefile.Win32 to compile
manually.
- The biggest problem in compiling is to get the yaDSKY and yaDEDA programs to build (or to
build properly). One
way around this, for the DSKY, to instead use the "DSKY Lite" built
into Stephan Hotto's LM_Simulator program, provided in the
"Contributed" folder of the development snapshot. This program is
written in the Tcl/Tk
scripting language and thus does not even need to
be compiled. You will, though, have to install Tcl/Tk.
This is explained in the build/installation instructions on the download page. There's no such
alternative available presently for yaDEDA.
It's Too Slow!
At the moment, Virtual AGC consists of
two parts: the core programs (like
yaAGC,
yaDSKY, etc.) and the contributed
LM_Simulator program. I
separate them because very different techniques and tools were used for
creating them, so they don't contribute to slowing down you computer in
the same way. Furthermore, the contributions of the various parts
are different on different platforms. Here are some approximate
timings I've made using the 20050716 development snapshot:
CPU
|
Speed
|
Operating
System
|
CPU
Utilization
|
Core
Programs
|
LM_Simulator |
Total
|
Without
Rotation
|
With
Rotation
|
Intel P4
|
2.8 GHz
|
Windows
XP Home
|
0-3%
|
65-70%
|
>95%
|
65-100%
|
Intel P4
|
2.53 GHz
|
Linux
|
0-3%
|
35%
|
40-45%
|
35-45%
|
G3
|
450 MHz
|
Mac OS X
|
50%
|
60%
|
90%?
|
110-140%
|
What you'll notice, undoubtedly, is that the simulation is going to
need a fast CPU to run all of the bits and pieces. If you don't
have a fast enough CPU, it doesn't observably affect the core programs,
but
has the symptom that
LM_Simulator
slows to a crawl, and responds increasingly slowly as time goes on,
because the backlog of unprocessed data increases.
So what is to be done about this? Well, I'm sure that over time
we'll be able to improve the speed of these programs, but that's not of
any immediate help to you. One thing you can do immediately,
assuming
you have the resources, is to take advantage of Virtual AGC's
client-server architecture. You can do things like running
LM_Simulator on one computer, and
the core programs on another computer. Splitting up the
bits and pieces this way has the additional advantage (if each computer
has its own monitor) of making it easier to see all of the various
controls without having them obscure each other.
Of course, if you're so inclined, you could also roll up your sleeves,
pitch in, and help us figure out how to speed up the simulation
programs.
Troubleshooting Running the Simulation
- If you're running the simulation by separately running yaAGC and yaDSKY rather than the provided
scripts (SimValidation, SimLuminary131, etc.), remember that
the two programs have to be
run from two different command-line windows. A reason why you
might want to do this is that
on some slow Win32 systems, there are
some timing problems if the startup scripts are used.
- There are currently
some quirks in the
startup and shutdown ordering of yaAGC
and yaDSKY. If you don't stick to my recommended
ordering, you will probably encounter problems. In Win32: You can't start
peripherals before you start yaAGC;
if you do, the programs will
not be able to communicate amongst themselves. In Linux (pre-20050131): You
can't terminate yaAGC before
terminating
peripherals; if you do, there will be
a timeout (which may be a minute or two) before the operating system
allows the port connecting the simulated CPU and peripherals to be
reused. (In Win32, command "netstat
-a" --- or in Linux, the command "netstat -a | grep 19697" --- is
useful for detecting this condition.) The startup/shutdown
procedure I'd recommend for both platforms is:
- Start yaAGC.
- Start all peripherals (like yaDSKY).
- Use to your heart's content.
- Stop all peripherals (like yaDSKY).
- Stop yaAGC.
- The main place (I think/hope) where things could go wrong would
be in the TCP socket interface connecting yaAGC and yaDSKY. If some
other service on your computer was already using port 19697 --- if, for
example, you were simultaneously running two copies of yaAGC or yaDSKY
--- then there could be a problem. You can check this by closing
out
all instances of yaAGC and yaDKSY (in Win32 with ctrl-alt-del,
or in Linux with "killall -KILL
yaDSKY" and "killall
-KILL yaAGC"), and then trying this: "telnet localhost 19697".
If telnet says it connected to something, then you definitely have
another service using this port, and you can work around it with the
--port command-line switch of yaAGC
and yaDSKY to choose a new
port. If not, then you
probably don't, and that's not the cause of your problem.
- Another possibility, I suppose, is that you may have a personal
firewall installed which is blocking port 19697. In that case,
you'll
have to reconfigure the firewall.
- Perhaps your computer is not even set up properly for networking,
which is necessary for any of the socket-based communications to
work. For example, you may not have an Ethernet card. These comments from Joe Durnavich
(thanks Joe!) may help if you have this problem and you're using Linux.
How do I Uninstall this Thing?
As you've undoubtedly noticed, the
installation procedure for Virtual AGC isn't very slick. The
uninstall procedure is even less slick. Here are the basics:
- In Win32: The binary installation can be removed simply by
erasing the c:\mingw directory. (However, if you happen to be a
software developer using MinGW, you won't want to do that because it
will mess up your other work. In that case, remove the directory
c:\mingw\share\yadsky, and remove the following files from
c:\mingw\bin: yaAGC.exe, yaDSKY.exe, yaYUL.exe, Luminary131.bin,
Colossus249.bin, Validation.bin, CheckDec.exe, Oct2Bin.exe,
webb2burkey-rope.exe, LM.ini, CM.ini, CM0.ini, SimLuminary131.bat,
SimColossus249.bat, and SimValidation.bat.) If you unpacked the
development snapshot to create a "yaAGC" directory, remove that
directory also.
- In Linux: If you installed from the binary package, just
remove the /usr/local/yaAGC directory. If you installed from
source, it's the same as above ("Win32"), except that the
installation directory will usually have been something like
/usr/local or your home directory (instead of c:\mingw), and so you
can't really
remove it. Instead, remove the files themselves, noting that the
".exe" and ".bat" extensions won't be present at the ends of the
filenames.
I'm drowning in Alphabet Soup! What does it all mean?
ACA
|
Attitude Controller
Assembler---the LM's hand-controller for pitch/roll/yaw adjustments.
|
AEA
|
Abort Electronics Assembly.
|
AGC
|
Apollo Guidance Computer
|
AGS
|
Abort Guidance System---a
separate computer aboard the Lunar Module
|
AOT
|
Alignment Optical
Telescope. Telescope used to make star sightings. By
monitoring the orientation of the telescope, the AGC could compute the
orientation of the spacecraft and use this information to calibrate the
IMU (see below).
|
CM
|
The Command Module---i.e., the
capsule.
|
CMC
|
Command Module Computer---i.e.,
the AGC in the CM.
|
CSM
|
The combined Command and Service
Modules.
|
G&N
|
Guidance and Navigation
|
GNCS
|
CM G&N Control System---i.e,
the AGC plus G&N measurement and control devices.
|
IMU
|
Inertial Measurement Unit.
This a stable platform (i.e., retains its orientation with respect to
the fixed stars rather than to the spacecraft) containing
accelerometers. By monitoring the accelerometers and the
orientation of the platform with respect to the spacecraft, the AGC can
compute the orientation of the spacecraft, as well as its position,
velocity, and acceleration.
|
LGC
|
Lunar Guidance Computer---i.e.,
the AGC in the LM.
|
LM
|
The Lunar Module---i.e., the
lunar lander.
|
PGNCS
|
("Pings".) The LM Primary
G&N Control System---i.e,
the AGC plus G&N measurement and control devices.
|
Is the moon landing a hoax?
Yes, but I've removed all references to
the hoax from the Luminary and
Colossus source code.
(Joke!)
How can the Virtual AGC project be contacted?
Email to
Ron Burkey <info@sandroid.org>.
If for some reason that doesn't work, then use apollo at ibiblio dot org
instead. (Sorry to spell it out like that rather than providing a
nice
link, but the spam leeches already have the former email address, and
there's no reason to make it any easier than necessary for them to get
the latter one.)
This page was last modified by Ronald Burkey on 2007-04-25.