Rise of the Falcon Heavy

Oscar Gordon

A Navy Turbine Tech who learned to spin wrenches on old cars, Oscar has since been trained as an Engineer & Software Developer & now writes tools for other engineers. When not in his shop or at work, he can be found spending time with his family, gardening, hiking, kayaking, gaming, or whatever strikes his fancy & fits in the budget.

Related Post Roulette

24 Responses

  1. Damon says:

    I saw this video and it was pretty cool.

    I’m actually hoping that the cost will come down enough that I’ll be able to have a “gravity moment”, like in the movie where Sandra Bullock is looking at the earth from orbit in a space suit. I’d pay good money to do that.Report

  2. Doctor Jay says:

    It has been my impression that autonomous landing control was the result of deep learning, which is the case in vehicles, at least in part. Is that not so?Report

    • Oscar Gordon in reply to Doctor Jay says:

      The deep learning is not necessary to landing a rocket, but it permits a considerable increase in the reliability of clean landings. Having computer hardware that is powerful and light enough to do that was important.

      To expand on that a bit, the math and control systems for computing course corrections and throttle positions and burn times are all well established. Having software that can bring all the various inputs together and quickly use them to adjust the outputs such that a soft landing is possible requires a bit of predictive, rather than simply reactive, capability. That is what the deep learning provides.

      If we apply that to cars, deep learning is how cars learn to judge, “Is that pedestrian going to step out in front of me?” or “Is that car next to me going to change lanes on top of me?”, etc.Report

    • None of the published descriptions of the real-time landing algorithm that I’ve seen mention learning. They appear to use a standard optimization approach, solved repeatedly. My understanding is that much of what makes that feasible depends on some recent work at Stanford that takes a description of the problem and (in minutes/hours) builds a problem-specific piece of code that can solve the problem very quickly. That code, running on board the rocket, is fast enough to use the optimization results to control the engine, aerodynamic surfaces, etc.

      Stanford’s blurb on the tool says that it works best for problems with less than 2,000 total coefficients (objective plus constraints). Choosing the right set of variables for that 2,000 might be a candidate for a neural network deep-learning sort of scheme.Report

      • Oscar Gordon in reply to Michael Cain says:

        @michael-cain

        You got a link?

        I ask because I had read that the learning algorithms were in the control software. Perhaps it’s a different set of learning algorithms, or it’s algorithms that are the result of learning?Report

        • veronica d in reply to Oscar Gordon says:

          Well, “deep learning” is optimization after all, so I can see how those terms would get conflated in the press.

          That said, I’d love to see a link. Optimization problems make me a happy veronica.Report

        • This is a superficial description of the problem, with follow-on references to more technical stuff. Blackmore’s been publishing this kind of stuff for years. The hard part is solving the problem for the optimum control settings fast enough to be able to respond. Here’s an example of the full-on math from when he was still at JPL. This is a paper on the Stanford tool that generates nearly-deterministic-time code for solving the convex optimization problems that SpaceX uses. I’m probably over the link limit, aren’t I?

          SpaceX has a summary page about their landing failures somewhere on their web site, or at least they used to. They seem to have had the software dialed in from the beginning.Report

          • Oscar Gordon in reply to Michael Cain says:

            Thank you, @michael-cain

            PS I think the link limit is 4 before it gets buggered.

            ETA: Gotta save this for another day, need to do a bug fix before release next week.

            Veronica, I think you’ll enjoy those links.Report

            • veronica d in reply to Oscar Gordon says:

              I’m gonna need to take a cold bath.Report

            • George Turner in reply to Oscar Gordon says:

              It occurred to me that if I take the conventional rocket equations and negate the ISP and drag vector (drag becomes thrust), then my rocket launches with high acceleration and near zero fuel, gaining fuel on the way up. If I can solve a launch trajectory problem such that my hypothetical rocket intersects the real rocket’s position with the velocity vector reversed, matching its angular positions, then my launch profile is the time inverse of the desired landing profile.Report

          • George Turner in reply to Michael Cain says:

            So, here’s my problem statement.

            Use the algorithms to build an object (probably propelled by compressed gas) that can be hurled into the air, possibly tumbling, and then make a controlled propulsive precision landing every time.

            I will add this to my list of strange tasks. Two weeks ago I was working on a propane fueled afterburner for a 5″ diameter ducted fan. I quickly prototyped a variable convergent nozzle section out of steel, but need to make a convergent/divergent section for maximum impact as a special effect for a fake spaceship for an engineering summer camp.Report

  3. Mike Schilling says:

    Ask any engineer, and they’ll tell you, hardware issues are always easier to handle than software.

    Because hardware problems often get fixed in software.Report

  4. Slade the Leveller says:

    I love the ambition this launch demonstrates. The U.S. space program has been frozen in the amber of the Apollo program for nearly 50 years.Report

  5. Fair Economist says:

    It’s not hardware vs. software, it’s a deterministic problem. vs. a non-deterministic problem. Calculating the projected trajectory for a given set of rocket thrusts is just a matter of grinding the math. Determining whether and when a pedestrian will step off a curve requires information about said pedestrian’s mind that aren’t available to anybody with current technology (even the pedestrian’s self-awareness is inadequate.) So you need experience, guesswork, and theory of mind, which are all far more complex that trajectory equations.Report

    • Oscar Gordon in reply to Fair Economist says:

      My apologies if I gave the impression it’s a hardware vs. software question. It’s not, hasn’t been for a very long time. It’s a, as you say, deterministic problem. vs. a non-deterministic problem. Although I’d argue that landing a rocket softly on target is less deterministic than you think*, but certainly considerably more so that trying to figure out what a human is going to do.

      *It isn’t getting on target that is an issue, we’ve been able to do that since the early days of guided weapons. It’s getting on target in one piece and in a state that re-use is cheaper than rebuild that get’s tricky. Managing rocket thrust when there is atmosphere and weather is much harder to do than managing it on, say, the moon. Our ability to throttle those rockets sufficiently has also advanced quite a bit since the days of Apollo.Report

  6. Oscar Gordon says:

    On a somewhat related note, SpaceX is going to put up two microsats this weekend to test out Satellite based broadband internet. Final orbit of the microsats will be about 1100 km, which tells me they are planning to put up a constellation of microsats for broadband service. At 1100 km, the signal lag won’t be terrible (unlike HughesNet, which is GeoSynch, or 35K+ km). I mean, LA to NYC is over 4000 km, and most folks won’t notice the signal lag (and the wires that carry that internet are longer than 4000 km).Report

    • Troublesome Frog in reply to Oscar Gordon says:

      They’re longer than 4000km and the signals going through them move slower than radio waves.

      On the flip side, the direct-ish trip from LA to NYC vs the trip from LA to NYC via an 1100km satellite the more important comparison.Report

      • On the gripping hand, with a few notable exceptions, propagation (speed of light) delay is seldom dominant in the total average delay calculation. LEO data service is much more likely to be dominated by transmission delay (how long to bang out the packet, one bit at a time, at the supported bits-per-second rate), queueing delay (how long will the packet sit in buffers in routers/switches), the quality of the terrestrial network the LEO satellite dumps your packets into, and for TCP, packet loss rate.

        When I run traceroute to http://www.google.com this morning, there are eleven hops. The largest part of the total delay occurs during the first eight, which all involve Comcast boxes here in the Denver area.Report

      • pillsy in reply to Troublesome Frog says:

        The distance to the satellite’s gonna add about 10% to the overall distance, tops.Report