In my day job I do data pipeline development and operations. That involves a bunch of AWS services and some custom wrappers we developed in-house. I spend a lot of time clicking around in web interfaces.
Recently I have fantasized about what it would be like to operate my environment with something like the ACE control room.
Need to set a flag on some Spark option? That’s literally a switch. Is something on fire? Look for a flashing red light. Need to send the output of a task to some other process? That’s a knob.
I think about this both in terms of literally making a control panel/room or a web interface equivalent.
A control room seems like something that needs a lot of forethought and deep understanding. How would that requirement along with the difficulty of pushing changes influence the design of a web interface?
Recently Ken obtained and shared some of the Roto-Tellite switches from mission control. Is that the 1960’s version of jQuery?
I made a little joke project a while back called "Keytarnetes" which used a MIDI controller (in this case a keytar from a Guitar Hero set) to run various actions against a Kubernetes cluster when you pressed the keys. It was really simple to hack together in a night using the mido python library. I basically just had a folder with shell scripts named after the notes and a process that polled for new keypresses and executed the script with the same name when that note that was pressed on the keytar. Maybe something like that could work for you?
I believe the current interest in Arduino, Raspberry Pi Pico, Mini SAM, and the like is because of an interest in how things worked when they were simpler and more mechanical. Especially since they allow for easy cross-breeding of modern computing with something more analog on a bread board or pHAT with any sensor configuration you can imagine.
It sounds like you would find some comfort in and around these devices.
To be serious, the Apollo testing was a combination of manual, semi-automatic, and automatic. You could program tests into the minicomputer and trigger them with a "start" button in the control room. The computer would carry out the steps for the test, check for parameters that were out of bounds, and display these on a CRT in the control room. Meanwhile, you could see other parameters on the gauges and chart recorders. So it was more advanced than you might expect.
It replaced a system where you'd radio a guy at the rocket and tell him to switch things on and off, and he'd tell you what happened. Needless to say, that was pretty unreliable.
I'm not able to check out the video right now, but I certainly will. I enjoy all things related to the Apollo program.
My understanding is that the autopilot in the LEM was very capable of flying the spacecraft, but there wasn't adequate sensor or image processing technology to allow the spacecraft to precisely choose a landing site free of obstructions. The human pilot wasn't necessarily essential for the mechanical act of landing, but was (in the first missions, at least) necessary for selecting a safe landing site.
I believe that is mostly correct. I think you will enjoy the video. It definitely taught me a lot.
It has been a while since I watched the video myself but here is my understanding:
The LEM had a “target” landing point and was fly-by-wire. There were two control modes, one for the descent and rendezvous (~”flight”) and one for landing. Both were fly by wire but one put the LEM in a desired orientation (as defined by astronaut input) and the second for landing.
In the landing configuration the LEM actually was landing itself and Armstrong was actually updating the target with the controls. Aldrin was instrumental in this process to manage literally everything else and calling out information for Armstrong who lined up the target point using special crosshairs on the window.
So in a sense all the LEMs “landed themselves”. Additionally they did have the capability to carry out (but not update) a pre-programmed landing. This was never done in reality but was simulated.
This device seems specific to its particular task. I wonder about the strange construction technique of pseudo-integrated-circuits on mini PCBs. It's hard to imagine that Control Data would come up with that specifically for this device. If I come across any other CDC systems that use the same technique, it will be informative.
As a kid, in the mid 70s, I recall playing with a board similar to the one depicted in the article, purchased for a few coins at a surplus store. It had rows and columns of small modules stacked that way which consisted of one transistor, a few diodes and a bunch of resistors. All modules pretty much the same, but much smaller, with only one transistor and a few other parts, unlike the ones showed in the article. The equivalent circuit was indeed some sort of basic logic gate. Transistors were all TO72 packaged; I can't recall the manufacturer, possibly Motorola or SGS, and showed an unknown label as they were probably high grade parts relabeled for that customer which btw I'm sure wasn't NASA since I'm in central Italy.
I salvaged what I could and ditched the board, so now you know who to blame if a rare piece of computer history has been lost forever:)
The groovy thing for proving you were an old-timer was a gate from a B5000, potted in perspex, and used as a paperweight. The gate consisted of two circuit boards, each about 2" square, with the discrete components wired between them, holding the two boards about 2" apart; so a gate was roughly a 2" cube.
It's a long time ago, and I haven't seen one for 40 years; but I think these things had two transistors in them. No ICs.
Probably it was done to save down time in the event of a failure, if something happened you’d just replace the affected module instead of the whole test box or to match certain characteristics, you build several modules and use the ones with similar parameters.
CDC shaped the computing landscape in Minneapolis and St. Paul for many many years. Too bad Mr. Cray isn’t still with us; he could probably answer a lot of these sorts of questions.
What strikes me about a unit like that is how it's just a small part in an undertaking where thousands of similar components had to be ready and interoperable within the decade.
Yes, it's like fractal levels of complexity. This box is a small part of the system to test a small part of a subsystem that's a small part of the Moon landing, but even this one piece is complicated, and had pages and pages of specifications.
I remember two versions of Finnish parliament voting machine. 1965 it was like restaurant refrigerator and 1975 it was just one wire-wrap board in a lunchbox. Never has there been such a giant leap in few years, methinks. And this is probably due to the Apollo program.
Correct me if I'm wrong, but they really did need such extreme measures against humidity etc then, right? The components we have today are better sealed, the materials are less likely to be affected by humidity, etc etc. Years of marginal improvements in epoxies mostly I think.
One of the testing documents describes the problems they had with corrosion, so it was a genuine problem. Part of the solution was more air conditioning, and the other part was making the units more resistant to humidity. Keep in mind that they were on the Florida coast, so there was a lot of humidity and salt.
Recently I have fantasized about what it would be like to operate my environment with something like the ACE control room.
Need to set a flag on some Spark option? That’s literally a switch. Is something on fire? Look for a flashing red light. Need to send the output of a task to some other process? That’s a knob.
I think about this both in terms of literally making a control panel/room or a web interface equivalent.
A control room seems like something that needs a lot of forethought and deep understanding. How would that requirement along with the difficulty of pushing changes influence the design of a web interface?
Recently Ken obtained and shared some of the Roto-Tellite switches from mission control. Is that the 1960’s version of jQuery?