Nailed it!!!
Nighttime, not expected to work, perfect!
I think I just woke up everyone in the house!
It’s getting scary when it begins to look normal.
That crazy Elon guy might actually be onto something.
Dude, just shoot them back up into space.
That was pretty cool, but I wish there was better video of the landing!
One key difference with this one is that they landed with three engines instead of just one. The reason is that this was a “hot” geostationary mission, and they had just a tiny bit of fuel left. As it turns out, it’s more fuel-efficient to run three engines rather than one.
Why is this? Well, basically, it’s because the longer you spend flying, the more time gravity has to act on the craft. A vehicle with low acceleration has to start the landing burn really early, and so there’s a long period of time where it’s not moving very fast, and gravity has a long time to accelerate the vehicle downward.
What you want to do instead is fall toward the landing pad as fast as you can, and then burn at the highest possible acceleration at the last second. Gravity has much less time to act and you get a nice fuel-efficient landing.
Of course this is much more difficult, because all of the maneuvering is more rapid, and you have to be more precise in the engine control. Not to mention that you can’t exceed the design margins of the vehicle. But it seems that SpaceX had no problems in this regard.
Kerbal Space Program is great for demonstrating these kinds of principles of rocketry. When fuel is tight on a landing, it’s as bad to burn too early as too late!
Some cool video of the landing. Got some pretty serious deceleration going on. If you look closely (especially in the third video), you can see that it starts with three engines going, then cuts to a single engine for the last second or two.
Man that is coming in hot (which is of course the whole point behind suicide burns, but jeeeeeeez.)
After watching tons of Ft McMurray wildfire videos the lingering flames on the landing legs make me twitchy.
We’re clearly witnessing the historic days when computers can so accurately control these machines the seemingly impossible looks normal. Because these rockets can’t hover they have to hit it just right. No human (well maybe somebody really good with tons of practice) could do this. But with advanced computers it will become commonplace.
For me, watching this happen, I have found myself feeling a surge of excitement for our future that I have never experienced before. Call it a cynicism, a spate of realism, but I always thought the future would be better, but in a steady, progressive way. Now I’m tapping into the feeling people felt during the race to the moon, or other times in history as mankind was involved in a historical acceleration.
A few clarifications:
First of all, the degree of control required of a rocket launch vehicle (without aerodynamic stabilization) during either ascent or descent is well beyond the capability of any human pilot, and always has been. Guidance and control systems perform feedback control at a rate on the order of 100 Hz, with actual interial and position measurements on the order of 500 Hz and filtered down. The perturbations aren’t just aerodynamic but also non-linear structural effects (e.g. modal response of the long L/D vehicle structure), sloshing effects for liquid propellants, the dynamic forcing functions of max-Q aerodynamics and stage separation/ignition, and highly nonlinear effects like the so-called “tail-wags-dog” which requires intensive modeling and simulation to understand and produce piecewise linear models that a real time controller can actually use.
The capability to perform a landing such as this isn’t really the result of “advanced computers”, unles by “advanced” you mean circa-1980s VSLI IC technology and the resulting processing throughput and robustness in a compact package. Although there have been revolutionary advances within processor manufacturing since that time, the basic architecture of flight computers has not really changed in that time, and in fact the LN-200 IMU that SpaceX currently uses has its origins in 1980s commercialization of military inertial measurement systems of that era. (SpaceX is currently developing an inhouse IMU to replace the LN-200, but that has more to do with inherent limitations of the LN-200 as a general purpose IMU and the desire by SpaceX to have design authority over this critial piece of the guidance and control system.)
Powered landings were being performed in the early 'Nineties, most notably by the McDonnell-Douglas DC-X. Although not flying as high or as fast as the F9v1.1 FS, it demonstrated the basic technology in use by SpaceX. The speed of newer processors, while allowing more calcutatons to be made per time increment and thus increasing the capability to handle more data, isn’t really critical to successful landings. What has advanced are better control algorithms (e.g. the ability to linearize the response models for use by a controller), careful management of the descent operation to minimize the propellant requirements an inert mass (SpaceX uses actuated gridfins for aerodynamic guidance, and cold gas RCS thrusters in addition to articulation of the engines), a workable scheme for terminal stabilization during the landing event (a balance of RCS response and controlled flexibility of the landing legs), and just experience in seeing what works and what doesn’t.
The willingness of SpaceX to try and fail and try again is actually the most crucial aspect to their success; one of the biggest problems with many advanced development programs is a managerial intolerance of any failures, even though failure from pushing the envelope of experience should be a routine and expected occurance during development. As I often point out, if you aren’t failing, you’re probably not learning much. The willingness of SpaceX to actually test and fail, rather than analyze using guesses until they are confidence of success, probably contributes to the speed at which they are developing the processes for successful landing. The question still remains as to the degree of reuse they will be able to achieve and the fiscal viability in reducing launch costs, but it is certainly an impressive technical achievement and an example of the kind of engineering approach (combining at-risk testing into the design analysis cycle) which developed earlier generations of rocket launch systems.
Stranger
I don’t think you can really downplay the effect of computer performance here. The DC-X, while impressive even by today’s standards, never really operated close to its margins. It had small, responsive engines with a wide throttle and gimbal range. And it never really got to a speed that could be considered fast.
It did all this with a 4.5 MIPS computer–slow even by the standards of the early 90s (as would be expected with aerospace-qualified equipment)! I strongly suspect that the newer control algorithms (which, as you mention, have made great progress in the past couple of decades) just couldn’t run in real time without modern computer performance. They aren’t, as far as I know, just running piece-wise linear models with precomputed trajectories. They are recomputing optimal trajectories on the fly given the current state. Although there might not be too much difference if it takes two seconds instead of one to compute a new optimal trajectory, you’re in deep trouble if it takes 1000 seconds.
I agree with 2gigch1 in that there’s a certain point where this stuff looks “magical”. I’m reminded of this video where a small moving cart inverts a triple pendulum. Inverting a single pendulum is easy, even for a human. Double–well, one might imagine that a human could do that if time were slowed down a lot, and with a lot of practice. But triple? Never gonna happen, no matter how much practice you have. And yet the computer seems to do it trivially.
Obviously it’s technically true that new computers do all the same things as old ones, just faster, but in practice it doesn’t work out that way–faster hardware allows a step change in what you can actually do with the computer. In part this is due to a virtuous cycle with software, where faster hardware makes the software engineers more productive. This is part of the reason why neural nets have made a comeback in AI. There’s nothing fundamentally new there compared to the work a few decades ago, but the extra performance has enabled so much extra productivity that they are now useful.
I should think that 4.5 MHz is darn fast when Newtonian physics are at play.
Control theory is, to a first approximation, about solving a large system of simultaneous differential equations. Rockets have a tremendous number of sensor inputs and control outputs and each of these relates to the others in a complicated way.
The control system also needs to make allowances for perturbations–winds, thrust variations, asymmetries in the aerodynamics, etc. One strategy for dealing with these is to perform Monte Carlo simulation–you compute your optimal trajectory hundreds or thousands of times, changing the inputs slightly with each one. You then pick a trajectory that’s not necessarily optimal by itself, but the one that allows the largest amount of variation given the constraints (like fuel). Each simulation might be relatively cheap, but running lots of them is not. I don’t know if SpaceX is doing this stuff in real-time (I know they do it offline), but it wouldn’t surprise me.
First of all, while faster processors add more capabilities in terms of the number of calculations that can be performed in a time interval, for a basic linear G&C model, the number of calculations are fairly trivial for any modern integrated circuit computer (by modern I mean 'Nineties era and newer). Even SpaceX with their nine engines requiring control in 18 different axes, plus individual throttling and so forth, is not really tasking the computing hardware. The Saturn V rocket with both the first and second stages (S-IC and S-II) using four gimballed engines had a G&C system that was roughly equivalent to about half of an Intel 8088 processor in terms of floating point operations per second. The control capability to land a vehicle the way SpaceX is currently doing has existed since at least the 'Eighties; it is just a matter of putting all of the other elements together to achieve that goal. This is nothing novel and in fact has been done previously, albeit not with the specific goal that SpaceX has (first stage reuse). The question still remains if the mass penalty of propellant to return the stage and the longevity of the state in reuse will provide a positive net return on investment.
The control system does have to correct for the various parameters that Dr. Strangelove states, but it doesn’t try to figure out which is which. A rocket launch vehicle autopilot is an idiot savant; it does exactly what it is instructed per the algorithms that tell it which linear models to use and how to apply them. Basically, when it detects a pitch/yaw rate of such and such, it responds with a certain proportionality. If it detects a loss in thrust or reduced control authority, it increases the propellant flow rates, and so forth. The algorithm can become quite sophisticated with such a complex vehicle as the F9 S1, but it is frankly far less taxing computationally than modern video game engines.
Monte Carlo simulations cannot be run “in real time” by definition. It is possible to run accelerated simulations of course, provided you have the computing power, but it isn’t done on the vehicle because there is no real need for it, and in order to evaluate a Monte Carlo sim you have to run the entire trajectory (or the critical segment of it) and then look at the enveloping cases to see if they have exceeded some margin or threshold. Monte Carlo sims are run to find realistic combinations of stressing cases (rather than just a “worst-on-worst-on-worst” case) and predict if a control limit or structural margin might be exceeded. Real time simulation attempts to predict and respond to inputs as they happen with minimal phase lag. SpaceX, like all space launch operators, runs Monte Carlo sims for both design margins (to determine wind placards) and so-called “day of launch” simulations, but I’m morally certain they use linear models in their actual vehicle control algorithms. The use of non-linear predictor-corrector models is challenging because they often tend to diverge from real solutions due to sensitivities, hence why control models often limit the system to responses well within stability regions, and notch out unstable responses. The use of Kalman filtering and other weighted average type predictors is often applied (I don’t know if SpaceX does this or not) but this is still just a more advanced type of linearization.
I agree that what SpaceX is doing is impressive and looks “magical” to the inexperienced eye, but it isn’t actually a result of recent advances in computing power or even control system design. It’s really just a case of taking pre-existing nominal capabilities and attempting (and failing, and attempting again) to do something that others have not really tried to do with similar vigor. To me, it is more impressive that they’ve been able to institute a system of non-ordnance separation and deployment devices using a combination of pneumatics and electromechanical devices, which is actually a surprisingly difficult achievement because of the conflicting requirements of such systems.
Stranger
Upon some further reading, I believe you’re right about the linear models–though what they’re doing is pretty clever.
First off, I’ll point out that the lead EDL guy at SpaceX is Lars Blackmore from MIT, and has a pretty impressive history in control theory. In particular, he did research in “lossless convexification”. For those watching, convexity is a property of the constraints applied to a system. The most intuitive example is just the allowed positional deviation–if the allowed set of positions corresponds to a convex function (say, a cone shape), then those constraints are convex.
Convexity gets more tricky when it comes to other constraints, such as the allowed levels of thrust from your engine. Because the Falcon 9 (and many similar vehicles) cannot shut down and restart their engines at will, there is both a minimum and maximum allowed thrust level at certain parts of the flight. This is a non-convex constraint.
At any rate, Blackmore, et al came up with a way to convert certain classes of non-convex systems to convex ones. Convex systems, and in particular linear ones, have relatively straightforward solutions, and these solutions have provably nice properties, such as guaranteed optimal solutions and bounds on stability.
They also convert non-linear variables into linear ones. In particular, the mass of the lander changes non-linearly–it follows the Tsiolkovsky rocket equation and thus the mass reduces logarithmically. However, they are able to perform a variable substitution to convert the non-linear constraint to a non-convex set of linear constraints. They then use their technique to make these constraints convex again.
Of course we don’t actually know if SpaceX is using these techniques, but given that Blackmore is their EDL lead, it’s not hard to imagine that they’re using them to some degree. The paper does mention recomputing the optimal trajectory on the fly based on the current state knowledge, though they leave the details to a future paper.
In the end, though, you appear to be correct in them using linear models, albeit with a conversion step from a non-linear (and non-convex) one.
Bumping for today’s launch, Thaicom 8, a “super” GTO (not sure what that entails – more higher?) launch rescheduled from yesterday’s scrub.
Of note – another hot first-stage recovery with no boostback burn and a potential three-engine landing burn on OCISLY.
Beginning of two-hour window begins at 5:39 EDT, when this post is 30 minutes old.
Three in a row. Pretty soon I won’t bother tuning in to watch live.
I don’t know the video cut out just as it was coming into view, then it jumped to it standing on the pad. I think they spliced in video from the previous landing 
Brian
Landing was a close thing. **Elon Musk **via twitter:
*Rocket landing speed was close to design max & used up contingency crush core, hence back & forth motion. Prob ok, but some risk of tipping.
Crush core is aluminum honeycomb for energy absorption in the telescoping actuator. Easy to replace (if Falcon makes it back to port).*
It’s one thing to do it; it’s another to make it look easy.
Same basic technology as the Apollo LM landing legs. Motivation then was that it’s “dry”–no hydraulic fluid, no oily seals, etc. (as you might have with traditional shock absorbers). Lightweight, too. It’s single-use, but that’s exactly what you want for landing legs.