This YouTube video discusses the kinds of control systems that SpaceX employed to bring the Starship booster back to the launch tower for a pinpoint catch by the tower’s “chopstick’s” arms.
I was going to comment on this magnificent engineering accomplishment a couple days ago but thought better of it since I realized that what I was going to say was rather silly. I was going to say that perhaps Elon Musk’s puzzling (to me, anyway) support of the ignorant (and despicable) Donald Trump is actually a reflection of Musk’s brilliance as an engineer. Maybe Musk, like Trump, thinks that he’s the only one who can get the USA to be a successful society because he views building such a society as a difficult control engineering problem, like catching the SpaceX Starship booster on reentry, that only a brilliant engineer like himself can solve.
But then I watched the video and saw (and heard) that the catching was done with “harms” rather than arms and realized this is probably a much better explanation of Musk’s support for Trump.
One of the control systems described in the video uses a Kalman filter algorithm, shown above; another is the PID, or Proportional-Integral-Derivative controller. This latter is the type of control system Bill Powers used in most of his simulations, such as those of pursuit tracking, and is described in the video as handling the last stages of landing the booster on the arms of the “chopsticks.” If you have seen the “inverted pendulum” simulation from Bill’s book, “Living Control Systems: The Fact of Control,” this is essentially the situation being handled by the booster’s PID controller, albeit in the X and Y dimensions, plus another controller for height above the chopsticks.
Bill Powers did not believe that the Kalman filter/predictive modeling approach finds any implementation in living control systems, if I understood him correctly.
PID refers to a type of output function in a control system. The output function in most PCT models is a “leaky integration”. It’s similar to PID; it’s kind of like PID with very little P and D. But it works rather well in terms of producing a model that fits data.
Yes, that’s correct. I feel the same way for several reasons. First, it seems implausible that the nervous system could implement a Kalman filter type physical model of the cause of time variations in even the simplest variables controlled by organisms. Second, computer models of organisms (mainly people) controlling such variables – models that contain no Kalman filtering – regularly account for around 99% of the variance in the behavior involved in producing such control. So it doesn’t seem that adding a Kalman filter could add much to the ability of PCT models to explain the behavior of living systems.
But I think the main reason why one doesn’t hear much about Kalman filters or, for that matter, PID controllers in PCT is because these are control engineering techniques used to stabilize control systems that are being built. As I noted in my chapter in the Interdisciplinary Handbook of PCT, PCT is an attempt to reverse engineer the controlling done by control systems that have already been built, so to speak.
The builder of living control systems has designed (via phylogeny) or is designing (via ontogeny) stable control systems using processes of which the nervous system is capable. Smart neurophysiologists, like Henry Yin, are working to figure out what those processes are. But for those of us interested in understanding behavior at the behavioral level, the main (or primary) goal of reverse engineering the behavior of living control systems is to figure out what variables they are controlling when we see them carrying out various behaviors.
Actually, the process of identifying controlled variables is the first step in both forward and reverse engineering of control systems. The difference is that in forward engineering the goal is to identify the variables that should be controlled while in reverse engineering the goal is to identify the variables that are being controlled.
For example, in designing the Starship booster catch system, the first step was to identify all the booster “state” variables as well as the variables involved in the “chopsticks” catching system that had to be controlled. Once these were identified the control engineering challenge was to design control systems that would successfully control these variables (keep them precisely at the required reference specifications in the face of continuous disturbance).
PCT is in the position of trying to figure out what variables a complex control system, like the booster catch system, is controlling and how it’s controlling them. And that is done by building models – usually computer models – that include our hypotheses about what variables are being controlled and see if our model behaves like the real thing.
Since the booster catch system has already been built using forward control engineering, it’s not really necessary to reverse engineer it. But the success of this booster catch system does suggest that it might be useful to reverse engineer the baffling living control system behind its development: E. Musk.
Actually, our typical PCT models implement a PID controller, usually without the I or D, or in other words, proportional control. The leaky integrator acts as a low-pass filter, which is necessary, especially in digital simulations of proportional control, to prevent the system from trying to erase the error in one time-step, which is a physical impossibility in real systems. (Without leaky integration in the output function, the simulation blows up.)
Actually, you can build successful digital simulations of proportional control systems by having the constant of proportionality (gain) set to a value less than 1.0. Depending on the nature of the variable controlled and the amplitude of prevailing disturbances, this constant might have to be much less than 1.0 in order for the system to be stable (not go into positive feedback oscillation). But such a low gain system will not be able to control very well.
But the point of my comment was to note that the nature of output functions (like PID) and other methods of stabilizing control systems (like Kalman filters) is more of a concern for engineers who are trying to build control systems (engineers doing forward engineering) than it is for PCT scientists who are trying to understand the behavior of living control systems that have already been built (scientists doing reverse engineering).
PCT scientists who are doing reverse engineering are most interested in figuring out the nature of the input functions that produce the variables that living control systems control. Control engineers who are doing forward engineering are less interested in the nature of input functions because all they have to do is design the system to control a signal that is an analog of the aspect of the environment that the system is supposed to control. This lack of interest in input functions can be seen in the models of control that are used by control engineers. Here’s a forward control engineering model that shows how to build a PID controller.
The Plant/Process in this diagram is a physical system – the environment in PCT models – that contains the variable aspects of that physical system that the control system has to control. For example, the Plant/Process might be the Starship booster and one of the variable aspects of that booster that has to be controlled is its acceleration. In that case, booster acceleration corresponds to the variable y(t) in the diagram.
The variable y(t) corresponds to the controlled variable, p(t), in PCT. But note that nowhere in the diagram do we see a box that corresponds to the input function that computes y(t). That’s because the control engineer cares mainly about designing an output function – in the form of the weightings of the P, I and D components of the PID controller – that produces an output variable, u(t), that keeps y(t) nearly equal to r(t) so that e(t) stays very close to 0.0. If a perceptual input function were included in this diagram it would be a box to the right of the Plant/Process box. An arrow from the Plant/Process box to this input function box would be something like a vector of physical variables that could be labeled X(t), and y(t) would be the output of that box.
I present this diagram only to show that control theory, as used by engineers building control systems, can be misleading when used to understand the behavior of living control systems. One of the extraordinary insights of Bill Powers, who learned control theory as a control engineer building – forward engineering – control systems, was that when using control theory to reverse engineer existing control systems, the first, and most important, step in the process is figuring out what variable(s) they are controlling – the y(t)'s in the engineering control diagram.